Audyt informatyczny, audyt bezpieczeństwa IT, pentest i skanowanie podatności — czym się różnią

Audyt informatyczny ocenia całą organizację IT, audyt bezpieczeństwa IT bada zabezpieczenia i zgodność z wymaganiami, skanowanie podatności automatycznie wykrywa znane luki, a test penetracyjny sprawdza, czy da się je realnie wykorzystać. Cztery nazwy opisują cztery różne zakresy, metodyki i formy wyniku. Audyt kończy się oceną względem wymagań, skanowanie listą sygnałów do weryfikacji, a test penetracyjny potwierdzoną ścieżką ataku.

Stan prawny na dzień 2 września 2026 r.

Czym jest audyt informatyczny, a czym audyt bezpieczeństwa IT

Audyt informatyczny odpowiada na pytanie o stan całego obszaru IT, a audyt bezpieczeństwa IT zawęża tę ocenę do zabezpieczeń i zgodności z konkretnym punktem odniesienia. Pierwszy obejmuje inwentaryzację zasobów, procesy utrzymania, dokumentację, ciągłość działania, licencje i sposób zarządzania zmianą. Drugi koncentruje się na politykach bezpieczeństwa, kontroli dostępu, konfiguracji, monitorowaniu i reagowaniu na incydenty.

Obie usługi opierają się przede wszystkim na tym, co NIST SP 800-115 nazywa technikami przeglądu (review techniques): przeglądzie dokumentacji, logów, zestawów reguł, konfiguracji systemów i sprawdzaniu integralności plików. Dokument definiuje badanie (examination) jako sprawdzanie, inspekcję, przegląd, obserwację lub analizę obiektów oceny, a ocenę (assessment) jako ustalenie, na ile skutecznie badany podmiot spełnia określone cele bezpieczeństwa. Audytor pracuje więc na dowodach i zapisach; eksploatacja systemu leży poza tą metodą.

Metodyczne ramy dla audytu systemu zarządzania bezpieczeństwem informacji opisuje ISO/IEC 27007:2020. Norma podaje wytyczne do zarządzania programem audytu, prowadzenia samych audytów oraz oceny kompetencji audytorów. To istotne przy audytach powiązanych z ISO/IEC 27001, gdzie liczy się nie tylko wynik, ale też niezależność audytora i udokumentowany sposób dojścia do ustaleń.

Skanowanie podatności a test penetracyjny — w skrócie

Skanowanie podatności wykrywa znane słabości automatycznie, a test penetracyjny potwierdza ich wykorzystanie i pokazuje konsekwencje. NIST SP 800-115 umieszcza obie aktywności w innych kategoriach technik: skanowanie podatności należy do technik identyfikacji i analizy celu, natomiast testy penetracyjne, łamanie haseł i socjotechnika do technik walidacji podatności. To rozróżnienie porządkuje cały spór o to, czy skaner wystarczy.

Praktyczna konsekwencja jest taka, że surowy raport ze skanera to lista sygnałów, nie lista potwierdzonych problemów — NIST SP 800-115 wskazuje wysoki odsetek fałszywych alarmów i konieczność interpretacji przez eksperta. W standardzie PTES analiza podatności jest tylko jedną z siedmiu faz testu penetracyjnego; eksploatacja i działania poeksploatacyjne w skanowaniu nie występują w ogóle. Całe porównanie obu podejść, razem z kryteriami wyboru, prowadzi osobny tekst: szczegółowe porównanie skanowania podatności i testu penetracyjnego. Zakres prac ofensywnych opisuje strona usługi testów penetracyjnych.

Porównanie czterech usług w jednej tabeli

Cztery usługi różnią się pytaniem, na które odpowiadają, stopniem automatyzacji, podstawą metodyczną i formą wyniku. To zestawienie porządkuje różnice metodyczne; zakres konkretnego badania powstaje dopiero na etapie specyfikacji.

Audyt informatyczny, audyt bezpieczeństwa IT, skanowanie podatności i test penetracyjny w sześciu kryteriach

Kryterium	Audyt informatyczny	Audyt bezpieczeństwa IT	Skanowanie podatności	Test penetracyjny
Główne pytanie	Jak działa i jak jest zarządzany obszar IT?	Czy zabezpieczenia spełniają przyjęte wymagania?	Jakie znane podatności występują w środowisku?	Czy podatności da się wykorzystać i z jakim skutkiem?
Podstawa metodyczna	Techniki przeglądu z NIST SP 800-115, wewnętrzne procedury organizacji	ISO/IEC 27007:2020, wymagania regulacyjne, techniki przeglądu z NIST SP 800-115	Techniki identyfikacji i analizy celu z NIST SP 800-115	PTES, OWASP WSTG 4.2, techniki walidacji podatności z NIST SP 800-115
Stopień automatyzacji	Niski, praca analityczna i wywiady	Niski, przegląd dowodów i konfiguracji	Wysoki, narzędzia z bazą sygnatur	Niski, przewaga pracy ręcznej
Zakres	Zasoby, procesy, dokumentacja, ciągłość działania	Polityki, kontrola dostępu, konfiguracja, monitorowanie, incydenty	Hosty, usługi sieciowe, aplikacje w powtarzalnym cyklu	Wybrana aplikacja, API, infrastruktura, środowisko OT lub scenariusz ataku
Wynik	Ocena stanu i dojrzałości wraz z planem uporządkowania	Lista niezgodności i rekomendacji względem punktu odniesienia	Lista wykrytych podatności wymagająca weryfikacji	Potwierdzone ścieżki ataku, dowody, ocena ryzyka i zalecenia naprawcze
Typowy wyzwalacz	Zmiana zarządu, przejęcie, brak wiedzy o własnym IT	Obowiązek regulacyjny, certyfikacja, wymóg kontrahenta	Stały cykl utrzymaniowy i nadzór nad wieloma systemami	Wdrożenie nowej aplikacji, istotna zmiana, wymóg klienta lub regulatora

Którą usługę wybrać w konkretnej sytuacji

Wybór usługi wynika z problemu, a nie z nazwy, która akurat pojawiła się w wewnętrznej korespondencji. W projektach, które prowadzimy, najczęstszym nieporozumieniem jest zamówienie audytu zgodności wtedy, gdy realnym problemem jest podatna aplikacja, oraz sytuacja odwrotna: zamówienie testu penetracyjnego, gdy organizacja potrzebuje uporządkowania dokumentacji i procesów przed kontrolą.

Sytuacja czytelnika a właściwa usługa

Sytuacja	Właściwa usługa	Uzasadnienie
Nowa aplikacja webowa lub API wchodzi na produkcję	Test penetracyjny	Potrzebne jest potwierdzenie podatności i błędów logiki biznesowej według przypadków testowych z OWASP WSTG
Organizacja przygotowuje się do kontroli lub certyfikacji systemu zarządzania bezpieczeństwem informacji	Audyt bezpieczeństwa IT	Liczy się porównanie stanu faktycznego z wymaganiami oraz udokumentowany, niezależny tryb pracy audytora
Brakuje aktualnej wiedzy o systemach, umowach, procesach i odpowiedzialnościach w IT	Audyt informatyczny	Bez inwentaryzacji i oceny procesów każdy test techniczny obejmie przypadkowy wycinek środowiska
Trzeba stale nadzorować znane podatności w dużej liczbie hostów	Cykliczne skanowanie podatności	Powtarzalność i koszt jednostkowy przemawiają za automatyzacją, przy założeniu weryfikacji wyników przez specjalistę
Zarząd pyta, czy napastnik dotrze do danych klientów mimo wdrożonych zabezpieczeń	Test penetracyjny o szerokim zakresie lub red teaming	Odpowiedzi udziela scenariusz obejmujący eksploatację i działania poeksploatacyjne, a nie lista podatności
Podmiot finansowy buduje program testowania cyfrowej odporności operacyjnej	Audyt bezpieczeństwa IT połączony z programem testów technicznych	Rozporządzenie DORA wymaga programu testowania, a nie pojedynczego badania

Czego wymagają regulacje: KRI, NIS2, DORA i ISO/IEC 27001

Regulacje rozróżniają audyty i testy techniczne, więc jedno nie zastępuje drugiego. Najwyższa Izba Kontroli w informacji o wynikach kontroli P/24/004 przywołuje obowiązek zapewnienia prowadzenia przynajmniej raz w roku okresowego audytu wewnętrznego z zakresu bezpieczeństwa informacji, wynikający z § 19 ust. 2 pkt 14 rozporządzenia w sprawie Krajowych Ram Interoperacyjności. Ta sama kontrola, obejmująca bezpieczeństwo informacji i ciągłość działania systemów w jednostkach samorządu terytorialnego, wykazała, że w dziewięciu z dwudziestu czterech skontrolowanych urzędów w 2023 r. corocznego audytu nie przeprowadzono albo prowadzono go nierzetelnie lub z naruszeniem zasady niezależności.

Dyrektywa 2022/2555 (NIS2) z 14 grudnia 2022 r. traktuje audyty bezpieczeństwa i skany bezpieczeństwa jako odrębne środki nadzoru. Praktyczną warstwę uzupełnia opracowanie ENISA „NIS2 Technical Implementation Guidance on Cybersecurity Risk Management Measures” w wersji 1.0 z 26 czerwca 2025 r., które wskazuje, że polityka testowania bezpieczeństwa powinna określać cele, zakres, rodzaje testów, częstotliwość, role oraz sposób usuwania wykrytych podatności. Częstotliwość pozostaje decyzją organizacji opartą na ryzyku.

Sektor finansowy działa dodatkowo pod rozporządzeniem 2022/2554 (DORA) z 14 grudnia 2022 r., które wymaga od podmiotów finansowych programu testowania cyfrowej odporności operacyjnej. Program to rozłożony w czasie, uporządkowany zestaw działań; pojedynczy raport z jednego badania go nie wyczerpuje. Po stronie systemów zarządzania punktem odniesienia pozostaje ISO/IEC 27001, a sposób prowadzenia audytów takiego systemu opisuje ISO/IEC 27007:2020.

Dyrektywa NIS2 jest wdrażana przepisami krajowymi i to one przesądzają, które podmioty podlegają obowiązkowemu audytowi bezpieczeństwa systemu informacyjnego, w jakim cyklu i przy jakich wymaganiach wobec audytorów. Zakres własnego obowiązku trzeba więc potwierdzić w aktualnym brzmieniu ustawy o krajowym systemie cyberbezpieczeństwa, zanim powstanie zapytanie ofertowe.

Od czego zależy zakres i koszt, i dlaczego nie podajemy kwot w artykule

Kwot ani widełek w tym artykule nie podajemy, ponieważ każda liczba bez opisanego zakresu wprowadza w błąd. Ta sama nazwa usługi obejmuje badanie jednej aplikacji i badanie kilkudziesięciu systemów w kilku lokalizacjach, a różnica w pracochłonności jest wielokrotna. Sensowne porównanie ofert zaczyna się od opisania zakresu, nie od pytania o cenę.

Na pracochłonność wpływa pięć policzalnych składników.

1. Liczba systemów, aplikacji, adresów IP i ról użytkowników objętych badaniem.
2. Głębokość testu: czy zespół ma potwierdzić podatności, czy przejść pełną ścieżkę ataku wraz z działaniami poeksploatacyjnymi.
3. Tryb pracy: black box bez wiedzy wstępnej, grey box z kontami i dokumentacją, white box z kodem źródłowym i konfiguracją.
4. Wymóg retestu po wdrożeniu poprawek.
5. Forma raportu, od zestawienia technicznego po materiał dla zarządu, audytora lub kontrahenta.

Dodatkowe dźwignie to środowisko testowe kontra produkcyjne, okna serwisowe i ograniczenia czasowe, konieczność podpisania zgód i uzgodnień z dostawcami hostingu, wymagania dotyczące poufności oraz język raportu. Każdy z tych parametrów da się opisać jednym zdaniem, a razem tworzą one specyfikację, na podstawie której oferty stają się porównywalne. Najszybciej powstaje to przez konfigurator zakresu, który prowadzi przez kolejne pytania o środowisko i oczekiwany wynik.

Jeśli zakres obejmuje infrastrukturę, warto wcześniej ustalić, które strefy sieci mają być od siebie odizolowane. Test sprawdza właśnie skuteczność tej izolacji, a podstawy wyjaśniamy w tekście o tym, na czym polega segmentacja sieci.

Najczęstsze pytania o audyt informatyczny i testy bezpieczeństwa

Czy skanowanie podatności może zastąpić test penetracyjny?

Nie, ponieważ skanowanie obejmuje wyłącznie wykrywanie znanych podatności, a NIST SP 800-115 zalicza je do technik identyfikacji i analizy celu. Test penetracyjny należy do technik walidacji podatności i zgodnie z PTES obejmuje siedem faz, w tym eksploatację oraz działania poeksploatacyjne. Skanowanie daje listę sygnałów do weryfikacji, test pokazuje, co napastnik jest w stanie z nimi zrobić.

Czy audyt bezpieczeństwa IT obejmuje testy techniczne?

Zależy to od zakresu ustalonego przed rozpoczęciem prac. Audyt bezpieczeństwa IT opiera się przede wszystkim na technikach przeglądu opisanych w NIST SP 800-115, czyli na analizie dokumentacji, konfiguracji, logów i zestawów reguł. Część audytów rozszerza się o skanowanie podatności lub testy penetracyjne wybranych systemów, ale taki zakres trzeba zapisać w umowie i w metodyce, bo zmienia czas prac i skład zespołu.

Jak często wykonywać audyt i testy bezpieczeństwa?

Częstotliwość wynika z przepisów oraz z oceny ryzyka. Najwyższa Izba Kontroli w kontroli P/24/004 przywołuje wymóg prowadzenia okresowego audytu wewnętrznego z zakresu bezpieczeństwa informacji przynajmniej raz w roku, wynikający z rozporządzenia w sprawie Krajowych Ram Interoperacyjności. Wytyczne ENISA do NIS2 wskazują, że organizacja sama określa w polityce testowania cele, zakres, rodzaje testów i ich częstotliwość. Testy techniczne powtarza się dodatkowo po istotnych zmianach w aplikacji lub infrastrukturze.

Czym różni się test black box od grey box i white box?

Różnicą jest zakres wiedzy przekazanej zespołowi testującemu przed rozpoczęciem prac. W trybie black box testerzy pracują bez danych wejściowych, podobnie jak napastnik z zewnątrz. W trybie grey box otrzymują konta użytkowników i podstawową dokumentację. W trybie white box dostają dodatkowo kod źródłowy i konfigurację. Szersza wiedza zwykle zwiększa pokrycie testu w tym samym czasie i wpływa na pracochłonność.

Co powinno znaleźć się w zapytaniu ofertowym na test bezpieczeństwa?

Zapytanie powinno wskazywać rodzaj usługi, listę systemów, aplikacji i adresów objętych zakresem, tryb testu, oczekiwaną metodykę oraz formę raportu. Warto dopisać, czy potrzebny jest retest po poprawkach, czy prace obejmą środowisko produkcyjne oraz kto po stronie organizacji odpowiada za zgody i okna serwisowe. Te informacje przesądzają o pracochłonności i o porównywalności otrzymanych ofert.

Jak Pentestica może pomóc

Pentestica prowadzi audyty bezpieczeństwa IT, audyty KRI oraz testy penetracyjne aplikacji webowych, API, aplikacji mobilnych i infrastruktury. Za tymi usługami stoi ponad 10 lat doświadczenia i setki zrealizowanych projektów. Pierwszy etap każdego zlecenia polega na ustaleniu, czy problem wymaga audytu, czy testu technicznego, bo ta decyzja przesądza o użyteczności raportu. Zakres prac audytowych opisano na stronie usługi audytu bezpieczeństwa IT.

Źródła

• NIST SP 800-115, Technical Guide to Information Security Testing and Assessment (National Institute of Standards and Technology, wrzesień 2008) – definicje testowania, badania i oceny oraz podział technik na przegląd, identyfikację i analizę celu oraz walidację podatności; wskazuje wysoki odsetek fałszywych alarmów skanerów.
• OWASP Web Security Testing Guide, wersja stabilna 4.2 z 3 grudnia 2020 r. – przewodnik po testowaniu bezpieczeństwa aplikacji webowych i zbiór dobrych praktyk stosowany przez testerów penetracyjnych.
• Penetration Testing Execution Standard (PTES), oficjalna dokumentacja standardu – siedem faz testu penetracyjnego, od uzgodnień przedprojektowych po raportowanie, w tym eksploatacja i działania poeksploatacyjne.
• ISO/IEC 27007:2020, Guidelines for information security management systems auditing – wytyczne do zarządzania programem audytu systemu zarządzania bezpieczeństwem informacji, prowadzenia audytów i oceny kompetencji audytorów.
• Najwyższa Izba Kontroli, Informacja o wynikach kontroli. Zapewnienie bezpieczeństwa informacji oraz ciągłości działania systemów informatycznych w jednostkach samorządu terytorialnego (P/24/004) – przywołuje obowiązek corocznego audytu wewnętrznego z § 19 ust. 2 pkt 14 rozporządzenia w sprawie Krajowych Ram Interoperacyjności oraz ustalenia dotyczące jego realizacji w skontrolowanych urzędach.
• Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 z dnia 14 grudnia 2022 r. (NIS2) – ramy środków na rzecz wysokiego wspólnego poziomu cyberbezpieczeństwa, traktujące audyty bezpieczeństwa i skany bezpieczeństwa jako odrębne środki nadzoru.
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554 z dnia 14 grudnia 2022 r. (DORA) – wymaga od podmiotów finansowych programu testowania cyfrowej odporności operacyjnej.
• ENISA, NIS2 Technical Implementation Guidance on Cybersecurity Risk Management Measures, wersja 1.0 z 26 czerwca 2025 r. – wskazuje elementy polityki testowania bezpieczeństwa: cele, zakres, rodzaje testów, częstotliwość, role i sposób usuwania podatności.