Test penetracyjny: klucz do udanego audytu cyberbezpieczeństwa

Audyt cyberbezpieczeństwa nie sprawdza, czy da się włamać do Twoich systemów. Sprawdza, czy potrafisz udowodnić, że nad nimi panujesz: że zabezpieczenia i procedury są wdrożone, a ktoś regularnie weryfikuje, czy naprawdę działają. Segregator z politykami takim dowodem nie jest. Jest nim raport z testu penetracyjnego, czyli z kontrolowanego ataku na własną infrastrukturę. Poniżej wyjaśniamy, co obejmuje audyt, kto może go przeprowadzić w świetle polskich przepisów i jakich dowodów technicznych audytor będzie od firmy oczekiwał. Piszemy dla osób odpowiedzialnych za IT i bezpieczeństwo, bez żargonu tam, gdzie da się go uniknąć.

Czym jest audyt cyberbezpieczeństwa i co obejmuje

Audyt cyberbezpieczeństwa to systematyczna ocena tego, czy organizacja spełnia wymagane standardy bezpieczeństwa i czy stosowane zabezpieczenia – organizacyjne, kadrowe i techniczne – odpowiadają przepisom. Audytor porównuje stan faktyczny z wymaganiami, opisuje odstępstwa i wskazuje, co trzeba poprawić. Chodzi o to, żeby słabe punkty znaleźli najpierw swoi, a nie ktoś, kto nie zapowie wizyty.

W Polsce obowiązek ma źródło ustawowe. Nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa (Dz.U. 2026 poz. 252) weszła w życie 3 kwietnia 2026 r. i to ona wdraża do polskiego prawa dyrektywę NIS2. Dzieli objęte firmy i instytucje na podmioty kluczowe (załącznik nr 1) oraz podmioty ważne (załącznik nr 2), a art. 15 ust. 1 nakazuje podmiotowi kluczowemu przeprowadzać audyt bezpieczeństwa systemu informacyjnego na własny koszt, co najmniej raz na trzy lata. Kalendarz jest już znany: wpis do wykazu do 3 października 2026 r., obowiązki z rozdziału 3 i podłączenie do systemu S46 od 3 kwietnia 2027 r., pierwszy audyt oraz pierwsze możliwe kary od 3 kwietnia 2028 r.

Audyt przeprowadza jeden z trzech podmiotów wskazanych w ustawie: akredytowana jednostka oceniająca zgodność, właściwy CSIRT sektorowy albo zespół co najmniej dwóch audytorów z certyfikatami z wykazu ministra cyfryzacji – CISA, CISM, CRISC, CISSP, CIA, certyfikat audytora wiodącego ISO/IEC 27001 lub ISO 22301, ISA/IEC 62443 Cybersecurity Expert. Audytora warto wybrać z wyprzedzeniem, bo termin audytu wyznacza kolejność wcześniejszych prac.

Audytor pyta natomiast wprost o dowody testowania i to jest część, którą dostarczamy. Podstawę ma w art. 8 ust. 1 pkt 2 lit. b ustawy, który wymaga, by system zarządzania bezpieczeństwem informacji obejmował „bezpieczeństwo w procesie nabywania, rozwoju, utrzymania i eksploatacji systemu informacyjnego, w tym testowanie systemu informacyjnego”. Z jednego projektu testowego wychodzi komplet, o który audytor poprosi: zakres i daty testów, znaleziska wraz z dowodami, oceny ryzyka, zalecenia naprawcze i pisemne potwierdzenie z retestu, że poprawki zadziałały. Testy prowadzą pentesterzy z certyfikatami klasy OSCP, a raport piszemy od razu w formie, którą audytor przyjmuje bez przerabiania – firma Haxoris ma własny certyfikat ISO 27001 od TÜV SÜD, więc wiemy z własnego wdrożenia, jak taki dowód ma wyglądać. Zakres, jaki ma sens pod NIS2 i ustawę o KSC, opisujemy na stronie testów penetracyjnych zgodnych z NIS2.

Sektor publiczny ma obowiązek starszy i częstszy. Rozporządzenie w sprawie Krajowych Ram Interoperacyjności (KRI, Dz.U. 2024 poz. 773) w § 19 ust. 2 pkt 14 wymaga od podmiotów realizujących zadania publiczne audytu bezpieczeństwa informacji co najmniej raz w roku. Dla urzędu, szpitala czy uczelni rytm pracy wyznacza więc ten przepis, a nie trzyletni cykl z ustawy o KSC.

Typowy audyt cyberbezpieczeństwa obejmuje kilka części:

• Przegląd dokumentacji i procesów: audytorzy czytają polityki bezpieczeństwa, zasady nadawania dostępów, plan reagowania na incydenty, procedury kopii zapasowych i sprawdzają, czy odpowiadają wymaganiom normy albo przepisu.


• Ocena rozwiązań organizacyjnych i kadrowych: czy odpowiedzialność za bezpieczeństwo jest przypisana konkretnym osobom, czy pracownicy przechodzą szkolenia, czy zarząd realnie nadzoruje ten obszar.


• Weryfikacja zabezpieczeń technicznych: konfiguracja firewalli, ochrona stacji roboczych, szyfrowanie danych wrażliwych, zarządzanie uprawnieniami, zbieranie logów i wykrywanie incydentów, a także zarządzanie podatnościami – w tym regularne testy.

Wynikiem audytu jest raport z ustaleniami: lista obszarów zgodnych z wymaganiami, wykaz stwierdzonych braków i zalecenia. Tam, gdzie audyt jest obowiązkowy, raportu zwykle oczekuje regulator, ale przydaje się on też zarządowi – jako zdjęcie stanu bezpieczeństwa na konkretny dzień.

Czego audytorzy oczekują od dowodów technicznych

Firmy audytorskie oceniają dowody techniczne pod jednym kątem: czy da się im wierzyć i czy da się je zweryfikować. Odhaczenie pola „wykonano” nie wystarczy. W praktyce liczą się trzy rzeczy.

1. Niezależność i aktualność testów: audytor woli, żeby testy wykonała niezależna firma z odpowiednimi kompetencjami. Testy własnego działu IT mają sens na co dzień, ale jako formalny dowód zwykle wypadają słabo – trudno być sędzią we własnej sprawie. Liczy się też data: raport starszy niż rok traci wartość dowodową, bo przez ten czas zmieniają się i systemy, i techniki ataku.


2. Treść zamiast surowych danych: zrzut z automatycznego skanera, pełen technicznych szczegółów i pozbawiony kontekstu, działa na audytora odstraszająco. Raporty złożone wyłącznie z wyników narzędzi budzą nieufność i zwykle kończą się prośbą o solidniejszy materiał. Czytelny raport z testu penetracyjnego działa odwrotnie: każde znalezisko jest w nim potwierdzone, a jego skutek opisany. Taki dokument audytor przyjmuje bez oporów.


3. Konkret i działania naprawcze: do każdej podatności powinien istnieć plan naprawy i ślad postępu prac. Sama lista błędów niczego nie dowodzi. Audytor chce zobaczyć nie tylko świadomość ryzyka, ale też udokumentowane usuwanie go w rozsądnym czasie – właśnie to odróżnia zabezpieczenia działające od zabezpieczeń opisanych.

Krótko: audytorzy szukają wiarygodnego dowodu, że firma regularnie testuje swoją odporność i naprawia to, co znajdzie. Dobry raport z testów penetracyjnych zamyka większość tych oczekiwań jednym dokumentem.

Dlaczego test penetracyjny przesądza o wyniku audytu

Wiele zabezpieczeń da się wdrożyć samodzielnie: napisać polityki, przeszkolić ludzi, uruchomić narzędzia. Test penetracyjny robi coś, czego żadne z tych działań nie zrobi – sprawdza w praktyce, czy to wszystko wytrzyma atak. Z perspektywy audytu ma to pięć konkretnych skutków.

• Potwierdza skuteczność zabezpieczeń: audyt ustala na papierze, że masz firewall, ochronę stacji roboczych i kopie zapasowe. Dopiero test pokazuje, czy firewall faktycznie zatrzymuje niebezpieczny ruch, czy raczej atakujący znajdzie obejście. Audyt pyta, czy potrafisz wykazać bezpieczeństwo; test pokazuje, ile go naprawdę jest.


• Wskazuje realne podatności: punkty wejścia do sieci, nieautoryzowany dostęp do systemów, wyciek danych wrażliwych. To ustalenia, na które da się zareagować od razu. Bez testu część z nich wyjdzie na jaw dopiero podczas audytu albo prawdziwego ataku.


• Zapobiega kompromitującym ustaleniom: audytor znajduje bazę danych wystawioną do internetu, o której nikt w firmie nie wiedział – i audyt może się skończyć oceną negatywną. Lepiej znaleźć taką dziurę wcześniej i ją załatać, a audytorowi pokazać zamknięty temat.


• Domyka zgodność z przepisami: regularnego testowania wymagają PCI DSS w płatnościach, SOC 2 czy norma ISO/IEC 27001. W Polsce dochodzi jeszcze RODO: Prezes UODO nałożył karę, wskazując m.in. na niewystarczające testowanie zabezpieczeń, którego wymaga art. 32 ust. 1 lit. d RODO (sprawa Morele.net, DKN.5130.2484.2019). Test penetracyjny przestaje więc być tylko dobrą praktyką i staje się elementem obrony przed sankcją.


• Buduje wiarygodność: raport z niezależnego testu to argument w rozmowie z partnerem, klientem i audytorem. Pokazuje, że bezpieczeństwo jest sprawdzane z zewnątrz, a nie deklarowane.

Test penetracyjny nie jest więc dodatkową przeszkodą przed audytem. Jest najkrótszą drogą do tego, żeby audyt przebiegł bez niespodzianek.

Jak wyniki testu penetracyjnego pomagają audytorowi i firmie

Dobry test penetracyjny kończy się kilkoma dokumentami: raportem, opisem metodyki, zestawieniem znalezionych podatności i rekomendacjami. Każdy z nich pracuje na dwie strony – dla zespołu technicznego i dla audytora.

• Szczegółowy raport z testów: główny dokument, który streszcza przebieg i wyniki prac. Zaczyna się od podsumowania dla kadry zarządzającej, czyli przeglądu najpoważniejszych ryzyk językiem zrozumiałym dla zarządu. Dalej idą statystyki wykrytych podatności z podziałem na poziomy ryzyka i część techniczna, gdzie każda podatność ma opis, warunki niezbędne do jej wykorzystania, proof of concept (PoC) i rekomendację. Raport podaje też zastosowaną metodykę – na przykład OWASP albo PTES – dzięki czemu czytelnik widzi, jak głęboko sięgały testy. Audytor dostaje wtedy komplet odpowiedzi w jednym miejscu: co testowano, co znaleziono i co z tym zrobiono. Twój zespół dostaje z tego samego dokumentu listę zadań.


• Zestawienie podatności z oceną ryzyka: każda pozycja ma przypisany poziom istotności, żeby było widać, co jest krytyczne, a co kosmetyczne. Dobry raport nie poprzestaje na ogólnej punktacji CVSS – tłumaczy, co dana podatność oznacza w tej konkretnej organizacji: wyciek danych klientów, przestój usługi, stratę finansową. Audytorowi to ułatwia pracę, bo widzi, że firma rozumie własne ryzyko. Zespołowi wskazuje kolejność napraw: podatności krytyczne warto zamknąć przed audytem i pokazać audytorowi jako rozwiązane.


• Rekomendacje i plan naprawy: sama lista błędów niewiele daje, dlatego do każdego znaleziska dopisujemy sposób jego usunięcia albo ograniczenia skutków. Zalecenia są konkretne i uszeregowane: zaktualizuj bibliotekę do wskazanej wersji, zmień konfigurację serwera, włącz uwierzytelnianie dwuskładnikowe dla kont administracyjnych. Dla audytora taki plan jest dowodem, że firma zna swoje słabe punkty i po kolei je zamyka. Dla zespołu to zwykle najbardziej wartościowa część raportu, bo skraca drogę od „mamy problem” do „problem jest naprawiony”.


• Metodyka i zakres testów: raport opisuje, co i jak było testowane. Aplikacje webowe testujemy zgodnie z metodyką OWASP ASVS, co oznacza, że sprawdzamy dziesiątki kategorii słabości – uwierzytelnianie, zarządzanie sesją, kryptografię, obsługę danych wejściowych, izolację sieci – a nie tylko kilka najgłośniejszych podatności. Pentester łączy pojedyncze błędy w łańcuch, którym da się wejść głębiej, tak jak zrobiłby to prawdziwy atakujący. Opisana metodyka daje audytorowi pewność, że test był systematyczny, a nie pobieżny, i pozwala niezależnie powtórzyć wybrane kroki.

Wyniki testu penetracyjnego to pomost między światem technicznym a światem audytu. Zespołowi dają listę zadań, audytorowi – dowód, że firma panuje nad ryzykiem. Retest po wdrożeniu poprawek zamyka ten cykl: potwierdza, że zalecenia trafiły do wdrożenia, a nie tylko do przeczytania.

Dobry test penetracyjny a automatyczny skan podatności – czym się różnią?

Oba pojęcia bywają mylone, a z punktu widzenia bezpieczeństwa i audytu dzieli je przepaść.

• Głębokość i pomysłowość kontra powierzchowność: skaner działa na sygnaturach i gotowych testach. Wykryje rzeczy oczywiste – brakujące aktualizacje, otwarte porty, słabe hasła ze słownika – ale niczego nie wymyśli. Pentester szuka błędów logiki biznesowej i łączy drobne słabości w jedno wejście. Dlatego dobry pentest znajduje to, czego skan nie znajdzie nigdy: obejście uwierzytelniania w procesie biznesowym albo ciąg podatności prowadzący do eskalacji uprawnień.


• Ręczna weryfikacja kontra fałszywe alarmy: narzędzia produkują długie listy potencjalnych problemów, z których wielu nie da się wykorzystać. Pentester sprawdza każdy wynik i odsiewa fałszywe alarmy, więc do raportu trafiają wyłącznie potwierdzone podatności. Firma nie traci czasu na kilkaset pozycji, tylko zajmuje się kilkunastoma, a audytor dostaje dokument bez balastu.


• Kontekst kontra ogólna punktacja: skaner przypisze podatności ogólną istotność według metryki, nie wiedząc nic o środowisku. Raport z pentestu wyjaśni, że SQL Injection w tej aplikacji otwiera dostęp do całej bazy klientów – i właśnie dlatego jest tu krytyczny. Takich scenariuszy żadne narzędzie samo nie napisze.


• Zalecenia kontra goła lista: wynik skanu to zwykle spis podatności z krótkim opisem i radą „zaktualizuj system”. Test penetracyjny podaje rozwiązanie dopasowane do systemu: który nagłówek ustawić, który moduł wyłączyć, którą logikę przebudować. Dobre firmy – Haxoris też – oferują potem retest i aktualizację raportu po wdrożeniu poprawek.


• Standardy kontra ograniczony zakres: skanery sprawdzają głównie znane podatności i konfiguracje. Pentester pracuje zgodnie z uznanymi standardami, na przykład OWASP ASVS, więc pokrycie obszarów bezpieczeństwa jest systematyczne i sięga znacznie dalej niż lista dziesięciu najpopularniejszych błędów.

Wniosek jest prosty: szybki skan albo pobieżnie wykonany test nie obroni się w audycie. Solidny test penetracyjny daje głębsze wyniki, a więc i większą wartość – dla bezpieczeństwa i dla audytora.

Podsumowanie: do audytu przygotuj się testem penetracyjnym

Audyt cyberbezpieczeństwa nie musi być stresem, jeśli firma przychodzi na niego przygotowana. Najwięcej daje tu test penetracyjny: pozwala wykryć i usunąć słabe punkty z wyprzedzeniem, daje audytorowi przekonujący dowód, a organizacji – realną odporność zamiast deklaracji. Bo ostatecznie nie chodzi o zaliczenie audytu, tylko o to, żeby atak, którego się boisz, po prostu się nie udał.

Haxoris wchodzi w ten proces po stronie technicznej. Robimy audyt bezpieczeństwa IT i testy penetracyjne zakończone raportem, który da się od razu wdrożyć – z opisaną metodyką, potwierdzonymi podatnościami i zaleceniami, jakich oczekuje audytor. Przygotowujemy też dowody techniczne pod certyfikację ISO 27001 oraz pod obowiązki z ustawy o KSC. Nie czekaj, aż luki znajdzie audytor albo ktoś zupełnie niezaproszony.

Powiązane usługi Haxoris: audyt bezpieczeństwa IT w firmie · testy penetracyjne do certyfikacji ISO 27001