2026-07-21 · PRZEWODNIK · Zespół Offensive Technology

Jak często należy wykonywać testy penetracyjne?

Krótka odpowiedź: co najmniej raz na 12 miesięcy oraz po każdej istotnej zmianie w systemach objętych zakresem. Ta dwuczęściowa zasada, kalendarz plus zmiana, stanowi praktyczne minimum we wszystkich standardach, z którymi styka się kupujący. Jedynie PCI DSS definiuje to jako twardy wymóg. SOC 2 i ISO 27001 w ogóle nie określają częstotliwości; opierają się na analizie ryzyka, a coroczny cykl stał się po prostu standardem oczekiwanym przez audytorów. Jeśli Twoje środowisko wdraża kod co tydzień lub przetwarza dane o wysokiej wartości, raz w roku to absolutne minimum, a nie docelowy punkt odniesienia.

Pytanie to powraca, ponieważ określenie „corocznie” brzmi jak odgórnie narzucona zasada. W przypadku jednego standardu tak właśnie jest. W przypadku pozostałych to konwencja wypracowana wokół podejścia opartego na ryzyku. Świadomość tych różnic zapobiega zarówno przepłacaniu, jak i brakom podczas audytu. Oto co dokładnie mówią poszczególne standardy.

Podsumowanie według standardów

Do przeprowadzenia testu większość kupujących motywują cztery czynniki: operator płatności, raport SOC 2, certyfikat ISO lub formularz ubezpieczeniowy. Tylko jeden z nich narzuca konkretną częstotliwość.

Dwuczęściowa zasada: kalendarz plus zmiana

Każda rzetelna odpowiedź dotycząca częstotliwości to w rzeczywistości dwie połączone zasady, a pominięcie którejkolwiek z nich tworzy lukę.

Część kalendarzowa wynika z faktu, że test penetracyjny jest badaniem w określonym momencie. Opisuje systemy objęte zakresem w oknie testowym pod kątem technik zdefiniowanych w zasadach zaangażowania. Odkrywane są nowe klasy podatności, publikowane są nowe eksploity, a Twój zespół stale wdraża nowe zmiany. Coroczny test resetuje ten zegar, zanim obraz stanie się zbyt nieaktualny.

Część związana ze zmianami wynika z tego, że kalendarz nie wie, kiedy przebudowano proces uwierzytelniania ani kiedy udostępniono nowe API. Test z marca nie mówi nic o usłudze uruchomionej w czerwcu. Dlatego każdy poważny standard łączy wymóg „co najmniej raz na 12 miesięcy” z zapisem „oraz po każdej istotnej zmianie”, i to właśnie tę drugą część kupujący pomijają najczęściej.

Co uznaje się za istotną zmianę

PCI DSS pozostawia definicję i uzasadnienie „istotności” samej organizacji, jednak przykłady branżowe są spójne. Każde z poniższych zdarzeń należy traktować jako sygnał do przetestowania dotkniętego nim zakresu, niezależnie od tego, kiedy odbył się ostatni coroczny test:

• Główne wydanie aplikacji lub przepisanie komponentu kluczowego dla bezpieczeństwa.
• Nowa usługa dostępna z internetu, poddomena lub API, które zwiększają obszar dostępny dla atakującego.
• Migracja do chmury lub istotna zmiana w architekturze chmurowej bądź IAM.
• Zmiana w uwierzytelnianiu, mechanizmie jednokrotnego logowania (SSO) lub obsłudze sesji.
• Zmiana w segmentacji sieci, regułach zapory sieciowej lub sposobie izolacji środowisk.
• Akwizycja lub nowa integracja z zewnętrznym dostawcą, która włącza cudzą powierzchnię ataku do Twojej.

Wspólnym mianownikiem jest ekspozycja. Jeśli zmiana wpływa na to, co jest dostępne z zewnątrz, w jaki sposób weryfikowana jest tożsamość lub gdzie znajduje się granica zaufania, ostatni test nie opisuje już rzeczywistości.

Co naprawdę mówią poszczególne standardy

PCI DSS v4.0 zawiera najbardziej nakazowe wymogi. Wymóg 11.4 nakłada obowiązek przeprowadzania wewnętrznych i zewnętrznych testów penetracyjnych co najmniej raz na 12 miesięcy oraz po każdej istotnej aktualizacji lub zmianie infrastruktury bądź aplikacji, zgodnie z udokumentowaną metodologią opartą na powszechnie akceptowanym podejściu branżowym, takim jak NIST SP 800-115. W przypadku stosowania segmentacji do izolowania systemów ze środowiska danych posiadaczy kart, segmentacja ta musi być testowana co najmniej raz na 12 miesięcy dla sprzedawców oraz co najmniej raz na 6 miesięcy dla dostawców usług, a wykryte podatności podlegają retestom po ich usunięciu. To najbardziej jednoznaczne określenie częstotliwości spośród wszystkich standardów.

SOC 2 nie określa częstotliwości. Kryteria AICPA Trust Services są sformułowane jako cele, a nie harmonogramy, więc brak w nich zapisu wymagającego corocznego testu. W praktyce audytorzy oczekują jego przeprowadzania co najmniej raz w roku, tak aby mieścił się w oknie obserwacji Type 2. Szczegóły dotyczące kryteriów odnoszących się do testów opisaliśmy w artykule czy SOC 2 wymaga testów penetracyjnych?

ISO/IEC 27001 wyraźnie opiera się na analizie ryzyka. Wymaga zarządzania podatnościami technicznymi i weryfikacji zabezpieczeń, uzależniając częstotliwość od własnej oceny ryzyka i planu postępowania z ryzykiem, a nie od sztywnego kalendarza. Certyfikowane organizacje zazwyczaj przyjmują coroczne testy jako uzasadnione minimum, przy czym aktywa o wyższym ryzyku są testowane częściej. Wybór częstotliwości wymaga własnego uzasadnienia, a nie przyjęcia gotowego sztywno narzuconego schematu.

Ubezpieczenie cybernetyczne zależy od ubezpieczyciela. Niektóre polisy pytają, czy testy są prowadzone regularnie, traktując odpowiedź „corocznie” jako oczekiwaną. Inne nie pytają o to wcale. Najrozsądniejszym krokiem jest dokładna weryfikacja konkretnego wniosku ubezpieczeniowego zamiast przyjęcia założeń, co jest tematem artykułu czy potrzebuję testów penetracyjnych do ubezpieczenia cybernetycznego?

Kiedy raz w roku to za mało

Coroczny test to absolutne minimum, a niektóre środowiska szybko z niego wyrastają. Testuj częściej, gdy:

• Wdrażasz kod w trybie ciągłym. Jeśli środowisko produkcyjne zmienia się co tydzień, coroczny test jest nieaktualny przez jedenaście miesięcy w roku. Zespoły w takiej sytuacji przechodzą na testowanie przy każdym wydaniu na krytycznych ścieżkach lub na model ciągłych testów, traktując pełny coroczny test jako punkt odniesienia.
• Przetwarzasz dane o wysokiej wartości. Płatności, dokumentacja medyczna oraz duże wolumeny danych osobowych podnoszą koszt ewentualnego błędu, co uzasadnia częstsze testowanie systemów mających z nimi styczność.
• Właśnie doszło do incydentu lub incydentu bliskiego skutku. Po incydencie, zdarzeniu potencjalnie wypadkowym lub wykryciu krytycznej podatności w wykorzystywanym komponencie, ponowne przetestowanie danego obszaru jest tańsze niż zakładanie, że poprawka była całkowicie skuteczna.

Żadne z tych działań nie zastępuje corocznego testu. Stanowią one jego uzupełnienie, ponieważ pełny zakresowo audyt przeprowadzony przez doświadczonych specjalistów charakteryzuje się zupełnie inną głębią niż ukierunkowany retest pojedynczej zmiany.

Błąd: traktowanie daty jako głównego rezultatu

Najczęstszym błędem dotyczącym częstotliwości jest traktowanie testu penetracyjnego jak certyfikatu z datą ważności, przeprowadzanie go w ostatnim możliwym dniu i nieprzekładanie wniosków na realne zmiany. Test zamawiany wyłącznie w celu odhaczenia wymogu ma zazwyczaj zakres zwężony tak, aby go zaliczyć, i jest na tyle powierzchowny, że pomija rzeczywiste wektory ataku. Data na raporcie satysfakcjonuje audytora, ale nie utrudnia przełamania zabezpieczeń.

Pomiędzy planowanymi testami poziom ekspozycji stale się zmienia, niezależnie od tego, czy go monitorujesz: zapomniana poddomena, usługa, która nigdy nie powinna być publiczna, czy poświadczenia w wycieku danych. Ciągła znajomość swojej zewnętrznej powierzchni ataku stanowi niedrogie uzupełnienie okresowych głębokich testów i nie jest tym samym co zakup pentestu. Jeśli nadal ustalasz, jakiej usługi tak naprawdę potrzebujesz, artykuł weryfikacja, skanowanie czy pełny pentest? wyznacza te granice.

Jak często należy wykonywać testy penetracyjne? Szybkie odpowiedzi

Jak często należy wykonywać testy penetracyjne?

Co najmniej raz na 12 miesięcy oraz po każdej istotnej zmianie w systemach objętych zakresem. Ta dwuczęściowa zasada stanowi praktyczne minimum we wszystkich kluczowych standardach. Środowiska o wysokim tempie zmian lub przetwarzające dane o wysokiej wartości powinny testować częściej, aż do testów przy każdym wydaniu lub w trybie ciągłym.

Czy PCI DSS wymaga corocznych testów penetracyjnych?

Tak. Wymóg 11.4 standardu PCI DSS v4.0 nakłada obowiązek przeprowadzania wewnętrznych i zewnętrznych testów penetracyjnych co najmniej raz na 12 miesięcy oraz po każdej istotnej zmianie infrastruktury bądź aplikacji. W przypadkach, gdy segmentacja izoluje środowisko danych posiadaczy kart, testowanie segmentacji musi odbywać się co najmniej raz na 12 miesięcy w przypadku akceptantów oraz co najmniej raz na 6 miesięcy w przypadku dostawców usług.

Jak często SOC 2 i ISO 27001 wymagają pentestów?

Żaden z nich nie określa stałej częstotliwości. Oba opierają się na analizie ryzyka: SOC 2 pozostawia kwestię dowodów audytorowi, a ISO 27001 wiąże testy z oceną ryzyka. W praktyce coroczny cykl stał się akceptowaną częstotliwością oczekiwaną przez audytorów, zaplanowaną tak, aby przypadała na okres obserwacji SOC 2 Type 2.

Kiedy należy przeprowadzać testy poza cyklem corocznym?

Po każdej istotnej zmianie: głównym wydaniu, udostępnieniu nowej usługi lub poddomeny w internecie, migracji do chmury, zmianie w uwierzytelnianiu lub SSO, zmianie w sieci bądź segmentacji, a także po akwizycji. Ostatni test opisywał jedynie stan środowiska z dnia jego przeprowadzania.

Źródła

• PCI Security Standards Council, PCI DSS v4.0 Requirement 11.4 (metodologia testów penetracyjnych, częstotliwość oraz testowanie segmentacji).
• AICPA Trust Services Criteria (SOC 2), sformułowane jako cele oparte na ryzyku bez stałej częstotliwości testów.
• ISO/IEC 27001, zarządzanie podatnościami technicznymi i weryfikacja zabezpieczeń w podejściu opartym na ryzyku.
• NIST SP 800-115, Technical Guide to Information Security Testing and Assessment, cytowany jako akceptowana metodologia.

Powiązane artykuły

• Czy SOC 2 wymaga testów penetracyjnych?
• Czy potrzebuję testów penetracyjnych do ubezpieczenia cybernetycznego?
• Ile kosztuje test penetracyjny?