Stwierdzenie “musimy przeprowadzić audyt bezpieczeństwa” oznacza dwie skrajnie różne rzeczy, zależnie od tego, kto je wypowiada. Dla dyrektora finansowego to weryfikacja zgodności z normą ISO 27001 i sprawdzenie, czy wymagane polityki są na swoim miejscu. Dla inżyniera systemowego — zatrudnienie etycznych hakerów, którzy przeprowadzą kontrolowany atak na firmowe serwery. Ta niejednoznaczność prowadzi do niewłaściwych oczekiwań, zakupu nieodpowiednich usług i fałszywego poczucia bezpieczeństwa.
Różnica między audytem bezpieczeństwa informacji a testem penetracyjnym (pentestem) sprowadza się do dwóch różnych pytań. Audyt jest jak inspekcja budowlana – sprawdzamy, czy budynek wzniesiono zgodnie z projektem i czy ma wymagane atesty, plany ewakuacyjne i sprawne systemy przeciwpożarowe. Pentest to próba kontrolowanego włamania – czy mimo wszystkich atestów da się wyłamać zamek albo obejść alarm. Żadne z tych działań nie zastępuje drugiego, a firma, która kupiła jedno myśląc, że ma drugie, dowiaduje się o tym dopiero podczas kontroli albo incydentu.
Dlaczego pojęcia “audyt bezpieczeństwa” i “pentest” są tak często mylone?
Źródłem nieporozumień jest to, że oba procesy mają ten sam nadrzędny cel — poprawę stanu cyberbezpieczeństwa organizacji — i oba kończą się raportem ze słabościami i rekomendacjami. Perspektywa, metodyka i zakres są jednak różne.
Audyt bezpieczeństwa ma podejście “z góry na dół” (top-down): zaczyna od strategii, polityk i procedur, a potem weryfikuje, czy działania techniczne i organizacyjne są z nimi zgodne — przez wywiady, analizę dokumentacji i przegląd konfiguracji wobec standardu. Audytor pyta: “Czy robimy właściwe rzeczy?”.
Test penetracyjny ma podejście “z dołu do góry” (bottom-up). Nie interesuje go dokumentacja, tylko praktyczna próba znalezienia i wykorzystania podatności w działających systemach. Pentester działa jak atakujący i pyta: “Czy robimy rzeczy we właściwy sposób?”.
Mylenie tych pojęć prowadzi do sytuacji, w której firma z certyfikatem ISO 27001 (wynik audytu) ma jednocześnie krytyczną podatność w aplikacji webowej (co wykazałby pentest). Z doświadczenia nFlo — w ponad 500 zrealizowanych projektach — widzimy ten wzorzec regularnie: około 40% organizacji z aktualnym certyfikatem ISO 27001 ma co najmniej jedną krytyczną podatność techniczną, którą pentest ujawnia w pierwszych dniach testów. I odwrotnie – systemy bywają technicznie “utwardzone” przy zupełnym braku procedur reagowania na incydenty (co wykazałby audyt).
📚 Przeczytaj kompletny przewodnik: Testy Penetracyjne: Testy penetracyjne - rodzaje, metodologie, przebieg
Czym jest audyt bezpieczeństwa informacji i jaki jest jego główny cel?
Audyt bezpieczeństwa informacji to systematyczny, niezależny i udokumentowany proces oceny (w ujęciu norm ISO). Weryfikuje, czy zabezpieczenia (techniczne i organizacyjne) oraz procesy spełniają określone kryteria. Mogą nimi być:
-
Standardy międzynarodowe: np. ISO/IEC 27001.
-
Regulacje prawne: np. dyrektywa NIS2, rozporządzenia KNF.
-
Standardy branżowe: np. PCI DSS dla sektora kart płatniczych.
-
Wewnętrzne polityki i procedury firmy.
Celem audytu jest ocena zgodności (compliance) i dojrzałości procesowej. Audytor nie próbuje “hakować” systemów — zbiera dowody przez rozmowy z pracownikami, analizę dokumentacji, przegląd logów i weryfikację konfiguracji.
Wynikiem jest formalny raport wskazujący obszary (nie)zgodności ze sprawdzanym standardem. Dla zarządu to narzędzie oceny dojrzałości programu, a dla partnerów biznesowych, ubezpieczycieli i regulatorów — dowód należytej staranności.
Czym jest test penetracyjny (pentest) i co ma on na celu?
Test penetracyjny (pentest) to kontrolowana i autoryzowana symulacja cyberataku, przeprowadzana w celu oceny faktycznego, technicznego poziomu bezpieczeństwa systemów. Celem jest praktyczna identyfikacja i próba wykorzystania (eksploitacji) podatności, zanim zrobią to prawdziwi cyberprzestępcy.
Pentester, czyli etyczny haker, wciela się w rolę atakującego i tymi samymi narzędziami próbuje przełamać zabezpieczenia. Nie chodzi o znalezienie teoretycznej słabości, ale o pokazanie związanego z nią ryzyka: nie „aplikacja jest podatna na SQL Injection”, lecz „tą podatnością udało się wykraść bazę klientów”.
W przeciwieństwie do procesowego audytu pentest ma ściśle zdefiniowany, techniczny zakres (np. konkretna aplikacja webowa, sieć zewnętrzna firmy, sieć Wi-Fi). Wynikiem jest raport techniczny opisujący każdą znalezioną podatność, kroki potrzebne do jej odtworzenia i rekomendacje usunięcia.
Które pytanie zadaje audyt, a które pentest — i komu pokazujesz wynik?
Audyt zadaje pytanie „czy da się wykazać”, pentest pytanie „czy da się wejść” — i to rozróżnienie, a nie metodyka, decyduje o tym, którą usługę kupić. Najkrótsza droga do decyzji prowadzi przez pytanie kto ma przeczytać wynik: regulator i dział zakupów klienta oczekują pokrycia, własny zespół inżynierski — głębokości.
| Aspekt | Audyt bezpieczeństwa informacji | Test penetracyjny (pentest) |
|---|---|---|
| Główne pytanie | ”Czy robimy właściwe rzeczy?” (zgodność z politykami i standardami). | ”Czy robimy rzeczy we właściwy sposób?” (praktyczna weryfikacja zabezpieczeń w boju). |
| Metodyka | Analiza dokumentacji, wywiady, przegląd konfiguracji, obserwacja. | Skanowanie, manualne próby włamania, eksploitacja podatności. |
| Skupienie | Szerokie: ludzie, procesy, technologia. | Wąskie i głębokie: technologia. |
| Wynik końcowy | Raport zgodności (compliance), ocena dojrzałości procesów. | Raport techniczny z listą podatności, dowodami ich wykorzystania (Proof of Concept) i rekomendacjami. |
| Komu pokazujesz wynik | Regulatorowi, jednostce certyfikującej, ubezpieczycielowi, działowi zakupów klienta, zarządowi. | Własnemu zespołowi inżynierskiemu i deweloperskiemu; zarządowi — w postaci wniosków, nie surowego raportu. |
| Kiedy wynik jest bezwartościowy | Gdy oczekujesz dowodu, że konkretna aplikacja jest nie do złamania — audyt tego nie sprawdza i nie twierdzi, że sprawdza. | Gdy oczekujesz dowodu pokrycia wszystkich obszarów wymaganych przez normę — pentest opisuje jeden odcinek techniczny w jednym dniu. |
Ostatni wiersz tabeli jest najczęstszym powodem, dla którego firma płaci dwa razy. Raport z pentestu bez ustaleń nie jest dowodem zgodności — mówi o wybranym zakresie technicznym, nie o tym, czy dla każdego wymaganego obszaru istnieje artefakt wykazujący wdrożenie środka. Wątek rozwijamy w tekście o tym, czym wykażesz zgodność w audycie bezpieczeństwa IT pod NIS2.
Czym różni się zakres audytu od zakresu pentestu według NIST SP 800-115 i CIS Controls?
Zakresy są rozłączne z definicji, a nie z umowy — i pokazują to dwa niezależne dokumenty branżowe. Przewodnik NIST SP 800-115 (Technical Guide to Information Security Testing and Assessment) rozróżnia trzy metody oceny: “testing, examination, and interviewing”. Testowanie to “the process of exercising one or more assessment objects under specified conditions to compare actual and expected behaviors”, badanie (examination) to “the process of checking, inspecting, reviewing, observing, studying, or analyzing one or more assessment objects” (NIST SP 800-115, Executive Summary).
Ten sam dokument dzieli techniki na trzy kategorie i umieszcza test penetracyjny wyłącznie w trzeciej. Kategoria pierwsza — Review Techniques — to przegląd dokumentacji, logów, zestawów reguł i konfiguracji; NIST opisuje ją jako pasywną, o “minimal risk to systems and networks” (sekcja 3). Kategoria trzecia — Target Vulnerability Validation Techniques — obejmuje, dosłownie za dokumentem, „password cracking, penetration testing, social engineering, and application security testing” (sekcja 5). Jedna bada, druga potwierdza podatność przez jej wykorzystanie.
Od strony siatki kontroli widać to jeszcze wyraźniej. CIS Critical Security Controls v8.1 to osiemnaście kontroli, a test penetracyjny jest jedną z nich — Control 18. Audyt oparty na tej siatce przechodzi przez wszystkie osiemnaście obszarów: inwentaryzację zasobów (Control 1 i 2), ochronę danych (3), konfigurację (4), konta i dostęp (5 i 6), logowanie zdarzeń (8), odtwarzanie danych (11), szkolenia (14), dostawców (15), reagowanie na incydenty (17). Pentest dostarcza dowodu dla jednej z osiemnastu pozycji — to nie opinia doradcy, tylko arytmetyka dokumentu, na który powołuje się sam kupujący.
Gdzie w tym wszystkim jest skan podatności?
Skan podatności to trzeci element, którego pominięcie generuje w praktyce zakupowej więcej nieporozumień niż sama różnica audyt–pentest. Skan jest zautomatyzowany: narzędzie porównuje wykryte wersje i konfiguracje z bazą znanych podatności i zwraca listę. Pentest jest pracą manualną: pozycje z tej listy są wykorzystywane i łączone w ścieżkę ataku. Skan mówi, co może być podatne; pentest — co z tego da się zrobić.
W siatce CIS to osobne kontrole: Control 7 (Continuous Vulnerability Management) mówi o ciągłym wykrywaniu i śledzeniu podatności w całej infrastrukturze, Control 18 (Penetration Testing) o testowaniu skuteczności zabezpieczeń przez “identifying and exploiting weaknesses in controls (people, processes, and technology), and simulating the objectives and actions of an attacker” (CIS Controls v8.1). Sam NIST zauważa, że jedno korzysta z drugiego: “penetration testing usually relies on performing both network port/service identification and vulnerability scanning” (NIST SP 800-115, sekcja 2.2) — skan bywa więc wejściem do pentestu, nigdy jego zamiennikiem.
Konsekwencja dla budżetu: skan prowadzi się ciągle, bo podatności przybywa codziennie, a pentest jest zdjęciem stanu z jednego dnia. Kupowanie raz w roku pentestu zamiast skanowania zostawia w kalendarzu jedenaście miesięcy bez nadzoru. Ten artykuł rozgranicza audyt i pentest; samo zestawienie skanu z pentestem rozpisaliśmy w tekście o różnicach między testem penetracyjnym a skanem podatności, a ciągłe wykrywanie — w dziale zarządzania podatnościami.
Kiedy regulacja wymaga testu technicznego, a kiedy przeglądu zgodności?
Regulacje rozróżniają obie klasy weryfikacji, a część z nich wskazuje test techniczny wprost. Najdalej idzie DORA (rozporządzenie (UE) 2022/2554, Dz.Urz. UE L 333 z 27.12.2022), którego rozdział IV obejmuje art. 24–27 i jest poświęcony w całości testowaniu.
Znamienny jest już art. 25 ust. 1: katalog wymaganych testów obejmuje jednocześnie „oceny podatności i skanowanie pod tym kątem”, „przeglądy kodu źródłowego”, „analizy braków”, „kwestionariusze” oraz „testy penetracyjne”. Jeden akt wymaga więc obu klas naraz i nie pozwala wybrać jednej zamiast drugiej. Art. 24 ust. 6 dokłada częstotliwość — „co najmniej raz w roku, przeprowadzenie odpowiednich testów wszystkich systemów i aplikacji ICT wspierających krytyczne lub istotne funkcje” — a art. 24 ust. 4 wymaga, by testy prowadziły „niezależne strony wewnętrzne lub zewnętrzne”.
Art. 26 wprowadza TLPT, czyli zaawansowane testy oparte na scenariuszach z analizy zagrożeń. Wskazane podmioty przeprowadzają je „nie rzadziej niż co trzy lata” (ust. 1), na „działających systemach produkcyjnych” (ust. 2); przy testerach wewnętrznych „co trzy testy” zlecają zadanie testerom zewnętrznym (ust. 8). Rozdział zamyka art. 27 — wymogi wobec samych testerów: certyfikat jednostki akredytującej lub przystąpienie do formalnych kodeksów postępowania (ust. 1 lit. c) oraz ubezpieczenie odpowiedzialności cywilnej z tytułu wykonywania zawodu (lit. e). Kto pisze, że DORA opisuje testowanie „w art. 24–26”, pomija właśnie ten artykuł — a to on rozstrzyga, kogo wolno zatrudnić.
Po drugiej stronie stoi dyrektywa NIS2 (dyrektywa (UE) 2022/2555, Dz.Urz. UE L 333 z 27.12.2022), której art. 21 ust. 2 wylicza obszary środków zarządzania ryzykiem — od analizy ryzyka i obsługi incydentów, przez ciągłość działania i łańcuch dostaw, po higienę cyberbezpieczeństwa i uwierzytelnianie wieloskładnikowe. Dyrektywa nie nakazuje testu penetracyjnego o określonej częstotliwości; wymaga, by dla każdego z tych obszarów istniał wdrożony i utrzymywany środek, co organ nadzoru weryfikuje dokumentacją. Na tym polega cała różnica: DORA nazywa test techniczny wprost, NIS2 pyta o pokrycie obszarów.
Kiedy moja firma potrzebuje audytu bezpieczeństwa, a kiedy testu penetracyjnego?
Wybór zależy od celu i od poziomu dojrzałości organizacji.
Wybierz audyt bezpieczeństwa, gdy:
- Chcesz uzyskać certyfikat zgodności z normą, taką jak ISO 27001.
- Musisz zademonstrować partnerom biznesowym lub regulatorom (np. w kontekście KSC/NIS2), że masz dojrzały System Zarządzania Bezpieczeństwem Informacji (SZBI).
- Chcesz uzyskać całościowy, strategiczny obraz programu bezpieczeństwa i zidentyfikować luki w politykach, procedurach i organizacji.
- Jesteś na początku drogi i potrzebujesz mapy drogowej.
Wybierz test penetracyjny, gdy:
- Chcesz zweryfikować faktyczny poziom zabezpieczeń nowej aplikacji webowej przed jej uruchomieniem produkcyjnym.
- Chcesz sprawdzić, czy infrastruktura sieciowa wytrzymuje ataki z internetu.
- Chcesz przetestować bezpieczeństwo aplikacji mobilnej lub sieci Wi-Fi.
- Regularnie wprowadzasz istotne zmiany w systemach i chcesz mieć pewność, że nie otworzyły nowych “drzwi” dla atakujących.
Od czego zacząć, jeśli firma nie miała jeszcze ani audytu, ani pentestu?
Zacznij od tego, co da się zrobić bez budżetu na usługę zewnętrzną: od inwentaryzacji. Nie ma sensu zamawiać testu zakresu, którego nie potrafisz wypisać. W siatce CIS ten krok nie przypadkiem stoi na pozycji pierwszej i drugiej. Dalsza kolejność zależy od tego, co wisi nad firmą najbliżej:
- Termin regulacyjny albo wymóg kontrahenta — pierwszy idzie audyt: to on produkuje artefakt, którym wykażesz zgodność, i pokazuje, których obszarów w ogóle nie obsługujesz.
- Usługa wystawiona do internetu, nigdy nietestowana — pierwszy idzie pentest, na wąskim i dobrze opisanym zakresie. Rozległość jest tu wrogiem: test „całej firmy” bez inwentaryzacji kończy się raportem o niskiej gęstości ustaleń. Jak wygląda taki zakres w praktyce, rozpisaliśmy w tekście o pentestach infrastruktury zewnętrznej — od inwentaryzacji do retestu.
- Nic nie pali się terminowo — najtańszy pierwszy krok to ciągły skan podatności i przegląd konfiguracji. Podnosi wartość późniejszego pentestu: tester nie spędzi połowy czasu na potwierdzaniu tego, co wypisało narzędzie.
Dojrzały cykl układa się potem tak: audyt wyznacza obszary i luki procesowe, skan działa w tle, pentest wchodzi punktowo tam, gdzie ryzyko jest największe, a retest zamyka pętlę. Błędem nie jest kolejność — błędem jest kupienie jednego w przekonaniu, że załatwia oba pytania.
Czy audyt i pentest wzajemnie się wykluczają, czy raczej uzupełniają?
Nie wykluczają się — ich wyniki działają w parze. Audyt identyfikuje brak procesowy: audyt ISO 27001 może wykazać, że firma nie ma formalnego procesu zarządzania podatnościami. Pentest pokazuje techniczną konsekwencję tego braku — że wobec braku procesu łatania kluczowy serwer jest podatny na znaną od roku lukę pozwalającą na pełne przejęcie.
Audyt dostarcza uzasadnienia procesowego („nie jesteśmy zgodni ze standardem”), pentest — dowodu ryzyka („nasze dane mogą zostać skradzione w ten sposób”). Pierwsze przekonuje zarząd, że trzeba zmienić sposób pracy; drugie, że trzeba to zrobić teraz.
W jaki sposób nFlo realizuje zarówno kompleksowe audyty, jak i zaawansowane testy penetracyjne?
W nFlo prowadzimy oba obszary jako osobne kompetencje, które spotykają się w jednym projekcie. Zespół ds. audytu i zgodności (GRC) realizuje audyty gotowości do certyfikacji ISO/IEC 27001, audyty zgodności z dyrektywą NIS2 i nowelizacją Ustawy o KSC oraz audyty oparte na NIST Cybersecurity Framework. Drugi zespół, specjaliści ds. bezpieczeństwa ofensywnego, realizuje zaawansowane testy penetracyjne: aplikacji webowych i mobilnych, infrastruktury sieciowej oraz symulacje ataków socjotechnicznych — metodyką manualną, nie samym automatycznym skanowaniem.
Wyróżnia nas łączenie obu perspektyw: wynik audytu bywa u nas punktem wyjścia do testu, który weryfikuje zidentyfikowane ryzyko procesowe w praktyce. Doświadczenie z ponad 500 projektów bezpieczeństwa, certyfikacje zespołu (OSCP, OSCE, CISSP, CEH, CREST) i 98% retencja klientów potwierdzają, że integracja audytu z pentestem daje pełniejszy obraz niż każde z tych działań osobno.
Zamów audyt lub test penetracyjny
Skorzystaj z doświadczenia naszych ekspertów:
- Audyty bezpieczeństwa - kompleksowa ocena zgodności z normami i regulacjami
- Testy penetracyjne - weryfikacja zabezpieczeń technicznych systemów
- Compliance NIS2 - przygotowanie do wymogów dyrektywy
- Red Team - zaawansowane symulacje ataków APT
- SOC as a Service - całodobowy monitoring bezpieczeństwa
Powiązane pojęcia
Poznaj kluczowe terminy związane z tym artykułem w naszym słowniku cyberbezpieczeństwa:
- Cyberbezpieczeństwo — Cyberbezpieczeństwo to zbiór technik, procesów i praktyk ochrony systemów IT,…
- Audyt bezpieczeństwa CIS — Audyt bezpieczeństwa CIS to ocena systemów informatycznych oparta o standardy…
- Audyt bezpieczeństwa IT — Audyt bezpieczeństwa IT to systematyczna ocena zabezpieczeń systemów…
- Audyt bezpieczeństwa — Audyt bezpieczeństwa to systematyczny proces oceny skuteczności polityk,…
- Testy penetracyjne — Testy penetracyjne (pentesty) to kontrolowany proces symulacji ataku na system…
Dowiedz się więcej
Zapoznaj się z powiązanymi artykułami w naszej bazie wiedzy:
- Klucze sprzętowe YubiKey w praktyce: jak wdrożyć FIDO2 i sprzętowe MFA w firmie
- Czym jest i skąd się bierze “okno ryzyka” w cyberbezpieczeństwie?
- Cyberprzemoc - czym jest i jak się przed nią bronić?
- Czym jest Deepfake i jak się przed nim bronić? - Kompleksowy przewodnik
- Czym są testy bezpieczeństwa systemów informatycznych i na czym polegają?
Tematy powiązane
Zobacz również:
