Dyrektor IT dostaje w budżecie na przyszły rok jedną pozycję: „testy penetracyjne — 1 szt.”. Rok temu wyglądała tak samo, dwa lata temu również. Nikt nie pyta, dlaczego jedna, bo odpowiedź wydaje się oczywista: „tak wymagają przepisy”. Problem w tym, że w większości polskich firm żaden przepis tego nie wymaga — a tam, gdzie wymaga, liczba brzmi zupełnie inaczej.
Ten tekst nie zawiera rekomendacji „raz na rok, chyba że coś się zmieni”. Interesuje nas rozdzielenie dwóch rzeczy, które w rozmowach o pentestach zlewają się w jedno: kadencji, którą narzuca prawo, i kadencji, która wynika z tempa zmian w systemie. Pierwsza jest sprawdzalna w tekście aktu, druga w rejestrze wdrożeń. Żadna z nich nie jest kwestią opinii.
Jak często trzeba wykonywać testy penetracyjne?
Poza sektorem finansowym żaden polski ani unijny przepis nie podaje liczby — a to oznacza, że kadencję wyznacza organizacja i musi umieć ją uzasadnić. Tam, gdzie liczba istnieje, jest konkretna: rozporządzenie DORA wymaga corocznych testów systemów wspierających funkcje krytyczne i testów TLPT nie rzadziej niż co trzy lata.
W praktyce oznacza to trzy różne odpowiedzi dla trzech różnych firm. Bank i dom maklerski mają kadencję zapisaną w rozporządzeniu. Podmiot kluczowy w rozumieniu ustawy o krajowym systemie cyberbezpieczeństwa ma zapisaną kadencję audytu, a nie testu. Średnia firma produkcyjna spoza obu tych kategorii nie ma zapisanego niczego i to właśnie ona najczęściej kupuje „jeden pentest rocznie”, bo tak podpowiada intuicja.
Czy polskie prawo w ogóle wymaga testów penetracyjnych?
Nie wprost — i da się to sprawdzić w pięć minut. Wyrażenie „penetracyjny” nie występuje ani razu w tekście jednolitym ustawy o krajowym systemie cyberbezpieczeństwa, ogłoszonym obwieszczeniem Marszałka Sejmu z 29 grudnia 2025 r. (Dz.U. 2026 poz. 20), ani w nowelizacji z 23 stycznia 2026 r. (Dz.U. 2026 poz. 252), obowiązującej od 3 kwietnia 2026 r. Wystarczy pobrać oba pliki z Dziennika Ustaw i użyć wyszukiwarki w czytniku PDF.
Ustawa mówi natomiast o testowaniu — tylko ogólniej. Art. 8 ust. 1 pkt 2 lit. b wymaga zapewnienia „bezpieczeństwa w procesie nabywania, rozwoju, utrzymania i eksploatacji systemu informacyjnego, w tym testowania systemu informacyjnego”, a lit. h — „polityk i procedur oceny skuteczności środków technicznych i organizacyjnych”. Obie litery opisują, co ma istnieć. Żadna nie mówi, jak często.
Jest jeszcze tryb, w którym testy wykonuje państwo. Art. 36a ust. 2 definiuje ocenę bezpieczeństwa jako przeprowadzenie testów bezpieczeństwa systemu informacyjnego w celu identyfikacji podatności, a wykonuje ją CSIRT MON, CSIRT NASK, CSIRT GOV albo CSIRT sektorowy. To nie jest obowiązek podmiotu — to uprawnienie organu, wymagające zgody podmiotu albo zlecenia organu właściwego (art. 36b ust. 1).
Kluczowy wniosek: ustawa o KSC nie nakazuje testów penetracyjnych i nie podaje ich częstotliwości. Nakazuje testowanie systemu informacyjnego jako element systemu zarządzania bezpieczeństwem informacji oraz ocenę skuteczności wdrożonych środków. Wybór metody i kadencji należy do podmiotu — razem z ciężarem uzasadnienia go przed organem.
Co dokładnie mówi ustawa o KSC o częstotliwości?
Jedyna liczba w ustawie dotyczy audytu, nie testu penetracyjnego. Art. 15 ust. 1 w brzmieniu nadanym nowelizacją: podmiot kluczowy przeprowadza, na własny koszt, co najmniej raz na 3 lata, audyt bezpieczeństwa systemu informacyjnego wykorzystywanego w procesie świadczenia usługi — „licząc od dnia sporządzenia i podpisania przez audytorów przeprowadzających audyt raportu z ostatniego audytu”.
Trzy szczegóły tego przepisu zmieniają planowanie budżetu. Po pierwsze, zegar biegnie od podpisania raportu, a nie od rozpoczęcia prac — opóźniony raport przesuwa cały cykl. Po drugie, obowiązek dotyczy podmiotu kluczowego; podmiot ważny nie ma cyklicznej kadencji audytu. Po trzecie, art. 16 pkt 2 daje na pierwszy audyt 24 miesiące od dnia spełnienia przesłanek uznania za podmiot kluczowy, podczas gdy pozostałe obowiązki rozdziału trzeba zrealizować w 12 miesięcy.
Do tego dochodzi tryb nadzwyczajny. Zgodnie z art. 15 ust. 1b organ właściwy do spraw cyberbezpieczeństwa może w każdym czasie nakazać podmiotowi kluczowemu przeprowadzenie zewnętrznego audytu, a podmiotowi ważnemu — w przypadku wystąpienia incydentu poważnego lub innego naruszenia przepisów ustawy. Decyzja podlega natychmiastowemu wykonaniu (ust. 1c), a kopia raportu trafia do organu w terminie 3 dni roboczych (ust. 1a). Kadencja trzyletnia jest więc podłogą, którą incydent potrafi unieważnić z dnia na dzień. Różnicę między audytem a testem rozwijamy osobno w tekście o tym, czym się różni audyt bezpieczeństwa od testu penetracyjnego.
Czy dyrektywa NIS2 narzuca częstotliwość testów?
Nie narzuca — i to jest najczęściej powtarzany błąd w rozmowach o zgodności. Art. 21 ust. 2 lit. f dyrektywy (UE) 2022/2555 wymaga „polityk i procedur służących ocenie skuteczności środków zarządzania ryzykiem w cyberbezpieczeństwie”. Ani słowa o metodzie, ani o kadencji.
Sprawdzenie jest równie proste jak przy ustawie. W całej dyrektywie wyrażenie „testy penetracyjne” pada dwa razy i oba wystąpienia leżą w motywach: raz przy opisie dostawców usług zarządzanych w zakresie bezpieczeństwa, raz przy wyliczeniu usług, z których mogą korzystać właściwe organy w ramach nadzoru. W części normatywnej — artykułach 1–46 — nie pada ani razu.
Konsekwencja praktyczna jest przyjemniejsza, niż się wydaje. Skoro dyrektywa nie narzuca liczby, nikt nie zarzuci firmie, że testuje „za rzadko wobec NIS2”. Zarzuci natomiast brak polityki, która tę częstotliwość ustala, i brak dowodu, że przyjęta kadencja wynika z oszacowanego ryzyka. Uzasadniona kadencja co 18 miesięcy jest w tym układzie mocniejsza niż nieuzasadniona kadencja roczna. Szerszy kontekst prawny zebraliśmy w artykule o prawie i regulacjach dotyczących testów penetracyjnych.
Gdzie regulacja podaje konkretną liczbę?
W rozporządzeniu DORA — i tylko tam liczby są jednoznaczne. Art. 24 ust. 6 rozporządzenia (UE) 2022/2554: podmioty finansowe inne niż mikroprzedsiębiorstwa zapewniają „co najmniej raz w roku, przeprowadzenie odpowiednich testów wszystkich systemów i aplikacji ICT wspierających krytyczne lub istotne funkcje”.
Drugą liczbę daje art. 26 ust. 1: zaawansowane testy z wykorzystaniem TLPT przeprowadza się „nie rzadziej niż co trzy lata”, przy czym właściwy organ może — w oparciu o profil ryzyka podmiotu i okoliczności operacyjne — zwrócić się o zmniejszenie albo zwiększenie tej częstotliwości. Sam TLPT rozporządzenie definiuje jako testy typu red team, naśladujące taktykę, techniki i procedury rzeczywistych napastników, prowadzone na działających na bieżąco krytycznych systemach produkcyjnych.
Trzecia liczba nie jest liczbą, tylko zdarzeniem — i to ona najlepiej ilustruje tezę tego tekstu. Art. 25 ust. 2 nakazuje centralnym depozytom papierów wartościowych i kontrahentom centralnym przeprowadzenie oceny podatności przed każdym wdrożeniem lub przeniesieniem nowych bądź istniejących aplikacji i elementów infrastruktury wspierających funkcje krytyczne. Prawodawca unijny sam zatem odchodzi od kalendarza tam, gdzie stawka jest najwyższa. Model TLPT opisaliśmy szerzej w tekście o testach penetracyjnych w sektorze finansowym pod DORA.
Dlaczego kalendarz jest złym wyzwalaczem testu?
Bo test daje obraz stanu z jednego dnia, a system zmienia się w każdym sprincie. NIST ujmuje to wprost w publikacji SP 800-115 Technical Guide to Information Security Testing and Assessment (wrzesień 2008), w rozdziale 6.2 poświęconym częstotliwości oceny: „Important technical considerations can also help determine testing frequency” — „istotne względy techniczne również pomagają wyznaczyć częstotliwość testowania”. Ten sam rozdział wskazuje, że zgodność z regulacją jest tylko jednym z czynników, obok krytyczności systemu i dostępnych zasobów.
Ta sama myśl leży u podstaw metodyki OWASP. Web Security Testing Guide otwiera rozdział o cyklu wytwarzania stwierdzeniem, że większość organizacji testuje oprogramowanie dopiero w fazie wdrożenia, i nazywa tę praktykę „generally a very ineffective and cost-prohibitive practice” — praktyką zasadniczo bardzo nieskuteczną i kosztowną. Rekomendacja jest odwrotna: wpleść testy bezpieczeństwa w każdą fazę cyklu.
Arytmetyka domyka argument. Zespół wdrażający co dwa tygodnie zmiany w aplikacji wystawionej do internetu ma między jednym a drugim rocznym pentestem około 26 wdrożeń, których nikt nie zweryfikował z perspektywy napastnika. Roczna kadencja opisuje wtedy jeden dzień z 365, a nie stan bezpieczeństwa aplikacji.
Kiedy zmiana w systemie powinna uruchomić test?
Wtedy, gdy zmienia się powierzchnia ataku, a nie objętość kodu. Nowy interfejs API wystawiony publicznie, migracja usługi do chmury, zmiana mechanizmu uwierzytelniania, wpięcie zewnętrznego integratora do sieci wewnętrznej, uruchomienie portalu dla kontrahentów — każde z tych zdarzeń tworzy ścieżkę dostępu, której nie było w zakresie poprzedniego testu.
Zmiany, które takiej powierzchni nie ruszają, nie powinny generować kosztu testu. Poprawka wydajnościowa w warstwie prezentacji, aktualizacja treści, refaktoryzacja bez zmiany kontraktu API — to materiał na skanowanie i przegląd kodu, nie na pełny pentest. Rozróżnienie warto zapisać w polityce jako listę zdarzeń wyzwalających, bo inaczej rozstrzyga je budżet, a nie ryzyko.
Praktyczna fiszka: zanim zaplanujesz kolejny test, wypisz z rejestru zmian wszystkie wdrożenia od daty ostatniego raportu i zaznacz te, które dotykały uwierzytelniania, uprawnień, integracji zewnętrznych lub ekspozycji do internetu. Liczba zaznaczonych pozycji jest lepszą przesłanką terminu niż data w kalendarzu.
Kiedy nowa podatność powinna uruchomić test poza kolejnością?
Wtedy, gdy jest aktywnie wykorzystywana w atakach i dotyczy technologii, którą faktycznie masz. Katalog Known Exploited Vulnerabilities prowadzony przez amerykańską agencję CISA jest tu najwygodniejszym źródłem, bo zawiera wyłącznie podatności z potwierdzonym wykorzystaniem w rzeczywistych atakach.
Skala tego strumienia bywa zaskoczeniem. W wydaniu katalogu oznaczonym 2026.08.24 znajduje się 1675 pozycji, z czego 274 dodano w ciągu ostatnich dwunastu miesięcy — średnio jedna nowa aktywnie eksploatowana podatność co niecałe półtora dnia. Ten pomiar odtworzysz samodzielnie: plik JSON katalogu jest publicznie dostępny, a każdy wpis ma pole dateAdded.
Nie każda z tych pozycji dotyczy Twojego stosu technologicznego i o to właśnie chodzi. Wyzwalaczem nie jest sam wpis w katalogu, tylko przecięcie katalogu z rejestrem Twoich zasobów. Bez aktualnego rejestru sprzętu i oprogramowania tego przecięcia nie da się policzyć — i wtedy organizacja wraca do kalendarza, bo nie ma czym go zastąpić.
Czym różni się kadencja skanowania od kadencji pentestu?
Skanowanie ma być ciągłe, test penetracyjny — zdarzeniowy. To dwie różne metody o różnych kosztach jednostkowych i różnym profilu wyniku: skaner porównuje stan systemu z bazą znanych podatności i może pracować codziennie, pentester szuka błędów logiki biznesowej, łańcuchów uprawnień i nadużyć procesu, których żadna baza nie opisuje.
NIST łączy obie w jedno zalecenie, opisując w SP 800-115 model, w którym regularne skanowanie podatności przeplata się z okresowymi testami penetracyjnymi. Wniosek operacyjny: pytanie „jak często pentest” ma sens dopiero wtedy, gdy skanowanie już działa w trybie ciągłym. Bez tego test penetracyjny staje się protezą monitoringu, czyli najdroższym możliwym sposobem wykrycia nieaktualnej wersji biblioteki. Temat rozwijamy w artykule o ciągłym testowaniu bezpieczeństwa.
Jak ustalić własną kadencję testów penetracyjnych?
Przez skrzyżowanie klasy systemu z tempem jego zmian, a nie przez wybór jednej liczby dla całej organizacji. Poniższa tabela jest narzędziem decyzyjnym: znajdź wiersz odpowiadający systemowi, sprawdź podłogę wynikającą z przepisu i dodaj wyzwalacze, które w Twoim przypadku uruchamiają test poza kolejnością.
| Klasa systemu | Podłoga z przepisu | Zdarzenie wyzwalające test poza kolejnością | Czego nie zastąpi kalendarz |
|---|---|---|---|
| System ICT wspierający funkcje krytyczne w podmiocie finansowym | Testy co najmniej raz w roku (DORA art. 24 ust. 6); TLPT nie rzadziej niż co 3 lata (art. 26 ust. 1) | Żądanie organu o zwiększenie częstotliwości TLPT | Wymogu niezależności testera (art. 24 ust. 4) |
| System świadczenia usługi w podmiocie kluczowym wg ustawy o KSC | Audyt co najmniej raz na 3 lata (art. 15 ust. 1); pierwszy w 24 miesiące (art. 16 pkt 2) | Nakaz audytu zewnętrznego wydany przez organ (art. 15 ust. 1b) | Terminu 3 dni roboczych na przekazanie raportu (art. 15 ust. 1a) |
| Aplikacja webowa wystawiona do internetu, wdrożenia częściej niż raz w miesiącu | Brak podłogi ustawowej | Zmiana uwierzytelniania, uprawnień lub kontraktu API | Weryfikacji zmian wdrożonych po dacie raportu |
| Infrastruktura wewnętrzna o niskim tempie zmian | Brak podłogi ustawowej | Wpięcie nowego dostawcy do sieci wewnętrznej | Kontroli faktycznej segmentacji sieci |
| Dowolny system oparty na komponencie z katalogu KEV | Brak podłogi ustawowej | Wpis dotyczący Twojej wersji komponentu w katalogu CISA | Retestu po wdrożeniu poprawki |
Tabela celowo nie zawiera rubryki „zalecana liczba testów rocznie”. Taka rubryka byłaby powrotem do kalendarza pod inną nazwą.
Od czego zacząć, jeśli nie masz ustalonej kadencji?
Od trzech dokumentów, które w większości firm już istnieją w kawałkach: rejestru systemów z przypisaną klasą krytyczności, rejestru zmian z datami wdrożeń i raportu z ostatniego testu wraz z datą jego podpisania. Zestawienie tych trzech źródeł pokazuje, ile zmian weszło do produkcji poza zakresem ostatniej weryfikacji — a to jest realna miara zaległości.
Drugim krokiem jest zapisanie kadencji w polityce, razem z uzasadnieniem. Organ nadzoru nie zakwestionuje liczby, którą podmiot potrafi wyprowadzić z oszacowanego ryzyka; zakwestionuje jej brak. W nFlo zaczynamy właśnie od tego zestawienia, zanim ustalimy zakres — testy penetracyjne planowane bez rejestru zmian zwykle mierzą to, co było łatwo zmierzyć, a nie to, co się w międzyczasie zmieniło.
Trzeci krok dotyczy tylko podmiotów kluczowych: sprawdź datę podpisania raportu z ostatniego audytu bezpieczeństwa i odlicz od niej trzy lata. To jedyny termin w polskim porządku prawnym, który biegnie niezależnie od tego, czy ktokolwiek o nim pamięta.
Źródła
- Ustawa z dnia 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa oraz niektórych innych ustaw (Dz.U. 2026 poz. 252), art. 8, art. 15, art. 16, art. 36a–36b, art. 49
- Obwieszczenie Marszałka Sejmu Rzeczypospolitej Polskiej z dnia 29 grudnia 2025 r. w sprawie ogłoszenia jednolitego tekstu ustawy o krajowym systemie cyberbezpieczeństwa (Dz.U. 2026 poz. 20)
- Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554 z dnia 14 grudnia 2022 r. (DORA), art. 3 pkt 18, art. 24–26
- Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 z dnia 14 grudnia 2022 r. (NIS2), art. 21 ust. 2 lit. f
- NIST, Technical Guide to Information Security Testing and Assessment, SP 800-115, wrzesień 2008, rozdz. 6.2
- OWASP, Web Security Testing Guide, rozdz. 2 — Principles of Testing, The SDLC is King
- CISA, Known Exploited Vulnerabilities Catalog, wydanie 2026.08.24 (1675 pozycji, stan na 24 sierpnia 2026 r.)
