Audyt bezpieczeństwa IT w 2026 r.: zakres, metodyka, dowody i wymagania prawne

Audyt, ocena bezpieczeństwa, skan podatności i pentest nie są tym samym

W praktyce terminy te bywają używane wymiennie, zwłaszcza w zamówieniach i ofertach. To prowadzi do nieporozumień, ponieważ każda z tych form badania odpowiada na inne pytanie i dostarcza innych dowodów.

Audyt ocenia badany przedmiot względem ustalonych kryteriów. Kryterium może stanowić przepis prawa, wymaganie normy, umowa, polityka wewnętrzna, zatwierdzony standard konfiguracji albo ich precyzyjnie wskazany zestaw. Audyt obejmuje planowanie, dobór próby, gromadzenie i ocenę dowodów, formułowanie ustaleń oraz raportowanie. Może dotyczyć systemu zarządzania, procesu, usługi albo określonego systemu informacyjnego.

Ocena bezpieczeństwa ma często cel bardziej diagnostyczny. Może sprawdzać projekt zabezpieczeń, konfigurację, odporność albo skuteczność kontroli bez wydawania formalnej opinii o zgodności. NIST SP 800-53A Rev. 5, w wydaniu z aktualizacją Release 5.2.0 z 27 sierpnia 2025 r., przedstawia konfigurowalne procedury oceny kontroli bezpieczeństwa i prywatności.^[4] Nie jest jednak polskim obowiązkiem prawnym.

Skanowanie podatności służy do systematycznego wykrywania określonych klas znanych podatności i błędów konfiguracji. Wynik skanera nie jest jeszcze ustaleniem audytowym. Trzeba sprawdzić, czy podatność rzeczywiście występuje, jaka jest ekspozycja systemu, czy istnieją zabezpieczenia kompensujące i jakie znaczenie ma problem w kontekście organizacji.

Test penetracyjny sprawdza, czy uzgodnione scenariusze ataku można zrealizować w praktyce i do czego prowadzi ich wykorzystanie. Wymaga jednoznacznej autoryzacji, reguł testu, określenia zakresu, dozwolonych technik, godzin działania, kanału awaryjnego i sposobu postępowania w razie zakłócenia. NIST SP 800-115 pozostaje użytecznym przewodnikiem po technicznych metodach testowania i ich ograniczeniach.^[12]

Te badania mogą się uzupełniać. Audyt bezpieczeństwa IT może wykazać, że organizacja posiada proces zarządzania podatnościami, a skanowanie podatności może sprawdzić, czy w badanym środowisku występują konkretne problemy. Test penetracyjny może wykazać rzeczywistą ścieżkę ataku, ale sam nie potwierdzi zgodności całego SZBI. Przegląd hardeningu może ocenić konfigurację względem zatwierdzonego standardu, ale nie zastępuje badania odpowiedzialności, ryzyka, ciągłości działania czy zarządzania incydentami.

Audyt certyfikacyjny jest jeszcze inną kategorią. Jest audytem strony trzeciej prowadzonym przez jednostkę certyfikującą w ramach procesu certyfikacji. ISO/IEC 27006-1:2024 określa dodatkowe wymagania wobec jednostek audytujących i certyfikujących SZBI zgodnie z ISO/IEC 27001.^[18] Audyt wewnętrzny, audyt doradczy ani raport firmy konsultingowej nie są certyfikatem.

Najpierw cel, kryteria i zakres

Najczęstszy błąd pojawia się wtedy, gdy organizacja zamawia "audyt bezpieczeństwa" bez wskazania, co dokładnie ma zostać ocenione. Sformułowanie "audyt zgodności z ISO 27001, NIS2 i RODO" również nie jest wystarczającym zakresem. ISO/IEC 27001 jest normą systemu zarządzania, NIS2 dyrektywą Unii Europejskiej, a RODO rozporządzeniem dotyczącym ochrony danych osobowych. Każdy z tych dokumentów ma inny zakres, adresatów i sposób wykazania zgodności.

Dokument inicjujący audyt powinien wskazywać co najmniej cel, kryteria, zakres organizacyjny i techniczny, okres objęty oceną, wyłączenia, ograniczenia, sposób doboru próby oraz zasady dostępu do dowodów.

• Cel powinien opisywać decyzję, którą ma wspierać raport. Może to być ocena zgodności z § 19 KRI, weryfikacja spełnienia wybranych obowiązków KSC, ocena gotowości do certyfikacji ISO/IEC 27001 albo sprawdzenie skuteczności wybranych zabezpieczeń.
• Kryteria powinny być wersjonowane i jednoznaczne. Jeżeli badany jest standard konfiguracji, trzeba wskazać jego wersję. Jeżeli badanie dotyczy prawa, należy określić właściwy akt i stan prawny. Jeżeli kryterium jest norma, warto podać dokładne wydanie. Mieszanie różnych wersji wymagań w jednej liście kontrolnej utrudnia późniejsze odtworzenie podstawy wniosku.
• Zakres organizacyjny i techniczny powinien obejmować wskazane podmioty, procesy, lokalizacje, usługi, systemy, dostawców, interfejsy i dane. Zakres nie powinien kończyć się na liście urządzeń. Audytor musi rozumieć, jakie usługi biznesowe są przez nie wspierane i które zależności mogą wpływać na wynik.
• Okres objęty badaniem jest szczególnie ważny przy logach, incydentach, przeglądach uprawnień, zmianach, kopiach zapasowych, testach odtworzeniowych i szkoleniach. Sprawdzenie stanu konfiguracji w jednym dniu nie dowodzi, że proces działał prawidłowo przez cały rok.
• Wyłączenia i ograniczenia trzeba opisać wraz z ich wpływem na pewność wniosków. Jeżeli audytor nie miał dostępu do środowiska chmurowego, nie mógł zweryfikować konfiguracji sieci albo otrzymał jedynie deklarację dostawcy, raport powinien to jasno wskazać.

Jak przebiega rzetelny audyt

ISO 19011:2026, opublikowana w maju 2026 r. jako czwarte wydanie, opisuje zasady audytowania, zarządzanie programem audytów, prowadzenie audytu i kompetencje osób uczestniczących w procesie.^[1] Wydanie z 2026 r. zastąpiło ISO 19011:2018 i silniej uwzględnia technologię, cyfryzację, środowiska wirtualne oraz podejście oparte na ryzyku.^[1] Dla audytów SZBI uzupełniające wytyczne daje ISO/IEC 27007:2020.^[2] Ocena samych zabezpieczeń może być wsparta przez ISO/IEC TS 27008:2019, które pozostaje opublikowane, choć jest w trakcie rewizji.^[16]

W praktyce proces audytu powinien obejmować kilka powiązanych etapów.

1. Planowanie ustala kryteria, próbę, harmonogram, role, kanały komunikacji, ograniczenia i ryzyka samego badania. Jeżeli planowane są testy aktywne, wymagają osobnej autoryzacji i zasad bezpieczeństwa.
2. Przegląd dokumentacji służy do ustalenia oczekiwanego sposobu działania systemu. Nie chodzi o liczenie procedur. Audytor powinien wiedzieć, kto jest właścicielem kontroli, jaki ma ona cel i jakie dowody powinny powstawać podczas normalnej pracy.
3. Wywiady pozwalają zrozumieć proces, ale deklaracja nie jest wystarczającym dowodem. Jeżeli administrator twierdzi, że wszystkie konta nieaktywnych pracowników są blokowane tego samego dnia, trzeba sprawdzić próbę rzeczywistych przypadków.
4. Obserwacja pozwala zobaczyć proces w działaniu. Może dotyczyć obsługi incydentu, procesu wydawania dostępu, pracy administratora, wejścia do serwerowni albo sposobu wykonywania testu odtworzenia.
5. Badanie próby jest podstawowym mechanizmem ograniczania kosztu audytu. Próbą mogą być konta użytkowników, zmiany, incydenty, urządzenia, dostawcy, kopie zapasowe czy uprawnienia uprzywilejowane. Sposób wyboru próby powinien odpowiadać ryzyku i celowi badania.
6. Weryfikacja techniczna może obejmować odczyt konfiguracji, zapytania do katalogu tożsamości, analizę polityk chmurowych, przegląd reguł zapory, analizę logów czy sprawdzenie stanu zabezpieczeń stacji roboczych. Testy aktywne, skanowanie podatności i pentest powinny mieć osobno zdefiniowany zakres i autoryzację.
7. Triangulacja polega na porównaniu kilku rodzajów dowodu. Polityka może wymagać MFA, administrator może twierdzić, że mechanizm jest wdrożony, a konfiguracja może pokazać wyjątek dla konta technicznego. Taka rozbieżność jest zwykle ważniejsza niż brak kolejnego dokumentu.
8. Uzgodnienie faktów nie oznacza negocjowania wyniku. Audytowany powinien mieć możliwość wskazania błędu faktycznego, brakującego dowodu lub nieprawidłowego zrozumienia architektury. Nie powinien natomiast oczekiwać usunięcia prawidłowo udokumentowanego ustalenia tylko dlatego, że jest ono niewygodne.
9. Plan działań jest potrzebny po audycie. Powinien wskazywać właściciela, termin, sposób naprawy, ryzyko pozostałe oraz dowód wymagany do zamknięcia ustalenia. Dla najważniejszych problemów warto przewidzieć retest.

Dowód: co jest wystarczające, a co tylko przekonujące

Największa różnica między rzetelnym audytem a przeglądem opinii dotyczy jakości dowodów. Dowód powinien być adekwatny do stawianego wniosku, możliwy do odtworzenia i chroniony przed nieuprawnioną zmianą.

Dokument może potwierdzać, że organizacja ustanowiła regułę. Nie dowodzi automatycznie, że reguła jest stosowana. Zrzut ekranu może pokazać stan konfiguracji, ale bez daty, identyfikacji systemu i kontekstu może być trudny do zweryfikowania. Eksport konfiguracji lub wynik zapytania wykonany w obecności audytora zwykle dostarcza mocniejszego dowodu niż obraz przesłany bez informacji o pochodzeniu.

Dla dowodów szczególnie wrażliwych trzeba ustalić bezpieczny sposób przekazania, szyfrowanie, retencję i usunięcie kopii roboczych. Audytor nie powinien zbierać sekretów "na wszelki wypadek". Pełne bazy danych, klucze prywatne czy hasła są zwykle niepotrzebne. Często wystarczą kontrolowane eksporty, sesja tylko do odczytu albo prezentacja dowodu przez właściciela systemu.

Próba daje racjonalną, a nie absolutną pewność. Jeżeli zbadano 12 z 900 kont, raport nie powinien stwierdzać, że wszystkie konta są prawidłowe. Powinien opisać wielkość i sposób doboru próby, wynik oraz ograniczenie wnioskowania. W obszarach wysokiego ryzyka można zwiększyć próbę albo zastosować analizę całej populacji przy użyciu zapytania lub skryptu.

Co może wejść w zakres audytu bezpieczeństwa IT

Zakres dobiera się do celu i ryzyka, a nie do uniwersalnego pakietu. W praktyce audyt może obejmować ład bezpieczeństwa, odpowiedzialność kierownictwa, zarządzanie ryzykiem, inwentaryzację aktywów, tożsamości i dostęp, konfigurację infrastruktury, bezpieczeństwo chmury, aplikacje, podatności, kopie zapasowe, ciągłość działania, monitoring, incydenty, dostawców i bezpieczeństwo fizyczne.

W obszarze tożsamości trzeba badać cały cykl życia konta: utworzenie, zmianę roli, przyznawanie uprawnień, przeglądy, dostęp uprzywilejowany, MFA, konta techniczne i odbieranie dostępu. Samo sprawdzenie, czy "MFA jest włączone", może nie wykryć wyjątków, słabych metod odzyskiwania konta ani niekontrolowanych kont serwisowych.

W infrastrukturze znaczenie mają stacje robocze, serwery, urządzenia mobilne, sieć, segmentacja, usługi administracyjne, zarządzanie konfiguracją i hardening. CIS Controls v8.1 może pomóc ustalić priorytety działań, a CIS Benchmarks dostarczać kryteriów technicznych dla konkretnych technologii, jeśli organizacja przyjęła je jako standard.^[13] CIS Controls nie są jednak metodyką audytu ani polskim prawem.

W chmurze trzeba badać nie tylko zasoby, lecz także organizację tenantów, tożsamości, role, klucze, logowanie, polityki, konfigurację sieci, kopie danych oraz podział odpowiedzialności z dostawcą. Brak dostępu do panelu administracyjnego dostawcy nie powinien być zastępowany założeniem, że "chmura jest bezpieczna z definicji".

W bezpieczeństwie aplikacji OWASP ASVS 5.0.0, wydane w maju 2025 r. i pozostające stabilnym wydaniem na 29 sierpnia 2026 r., może służyć jako katalog weryfikowalnych wymagań technicznych dla aplikacji internetowych i usług webowych.^[14] Audyt aplikacji może być uzupełniony przeglądem kodu, testami penetracyjnymi, analizą zależności i weryfikacją procesu wytwarzania oprogramowania.

W zarządzaniu podatnościami trzeba zbadać źródła informacji, częstotliwość skanowania, sposób weryfikacji wyników, priorytetyzację, terminy napraw, obsługę wyjątków oraz ponowne sprawdzenie. Audyt podatności nie powinien opierać się wyłącznie na wyniku CVSS.

CVSS 4.0 opisuje dotkliwość techniczną podatności przy użyciu grup metryk Base, Threat, Environmental i Supplemental.^[15] FIRST wyraźnie wskazuje, że organizacja powinna wzbogacać ocenę o informacje o zagrożeniu i własnym środowisku, a czynniki takie jak wymagania regulacyjne, straty finansowe, liczba dotkniętych klientów czy reputacja pozostają poza zakresem CVSS.^[15] Wynik CVSS jest więc wejściem do oceny ryzyka, a nie gotową oceną ryzyka organizacji.

W ciągłości działania trzeba sprawdzać nie tylko istnienie kopii zapasowych, ale także cele odtworzeniowe, zależności, ochronę kopii, separację, testy i wyniki odtworzenia. RPO opisuje docelowy punkt odtworzenia, czyli akceptowalną utratę danych wyrażoną w czasie. RTO opisuje docelowy czas przywrócenia usługi. Harmonogram wykonywania kopii nie jest automatycznie dowodem spełnienia RPO ani RTO.

Monitoring i incydenty wymagają oceny źródeł logów, synchronizacji czasu, retencji, integralności, reguł detekcji, eskalacji, odpowiedzialności i dowodów z rzeczywistych spraw. W tym obszarze audyt bezpieczeństwa IT może być uzupełniony oceną SOC 24/7: ważne jest nie tylko to, czy logi są zbierane, ale czy krytyczne scenariusze są widoczne, ktoś je analizuje i istnieje realna możliwość reakcji.

Jak opisywać ustalenia i ryzyko

Dobre ustalenie powinno pozwolić odbiorcy zrozumieć, co było wymagane, co stwierdzono i dlaczego ma to znaczenie. Minimalny zestaw obejmuje kryterium, stan faktyczny, dowód, zakres próby, możliwą przyczynę, skutek oraz zalecenie.

Warto rozdzielić ocenę zgodności od oceny ryzyka. Zgodność odpowiada na pytanie, czy określone wymaganie zostało spełnione. Ryzyko opisuje prawdopodobieństwo i skutek niepożądanego zdarzenia w kontekście aktywów, ekspozycji, zagrożeń i istniejących zabezpieczeń.

Naruszenie obowiązku prawnego może być formalnie istotne nawet wtedy, gdy techniczne prawdopodobieństwo szkody jest niewielkie. Z drugiej strony poważna ścieżka ataku może wynikać z połączenia kilku drobnych słabości i nie odpowiadać jednej pozycji z listy kontrolnej.

Nie należy automatycznie mnożyć skali "prawdopodobieństwo x skutek", jeśli organizacja nie zdefiniowała znaczenia tych wartości. Macierz ryzyka jest użyteczna tylko wtedy, gdy kryteria są powtarzalne, właściciele rozumieją skalę, a wynik prowadzi do decyzji.

Co powinien zawierać raport

Raport powinien być możliwy do przeczytania przez dwa różne grona odbiorców: kierownictwo oraz osoby odpowiedzialne za naprawę. Dlatego dobrym rozwiązaniem jest rozdzielenie streszczenia zarządczego od szczegółów technicznych.

Streszczenie dla kierownictwa powinno przedstawiać najważniejsze ryzyka, obowiązki, zależności i decyzje. Nie powinno być listą portów, adresów IP i nazw parametrów konfiguracji.

Część metodyczna powinna wskazywać cel, kryteria, zakres, daty, metodę doboru próby i ograniczenia. Dzięki temu odbiorca może ocenić, na ile daleko wolno uogólniać wnioski.

Każde ustalenie powinno mieć identyfikowalny dowód. W raporcie szeroko dystrybuowanym nie trzeba umieszczać sekretów, pełnych fragmentów konfiguracji czy danych osobowych. Szczegóły mogą zostać przeniesione do chronionego załącznika technicznego.

Priorytet naprawy powinien wynikać z ryzyka, obowiązku prawnego, zależności i wykonalności. Zalecenie "wdrożyć MFA" jest słabe, jeśli nie wiadomo, dla jakich kont, w jakich systemach, z jakimi wyjątkami i jak zostanie potwierdzona skuteczność.

Raport nie powinien obiecywać pełnego bezpieczeństwa ani braku przyszłego incydentu. Opisuje stan określonego zakresu w określonym czasie i na podstawie określonych dowodów.

Jak dobierać metodyki i standardy

ISO 19011:2026 jest punktem odniesienia dla zasad i organizacji audytów systemów zarządzania.^[1] Nie jest normą certyfikacyjną dla organizacji i nie zastępuje kryterium badanego systemu.

ISO/IEC 27007:2020 dotyczy audytowania SZBI i uzupełnia ISO 19011.^[2] Na 29 sierpnia 2026 r. wydanie z 2020 r. nadal jest opublikowane, ale ISO prowadzi jego rewizję.

ISO/IEC 27001:2022 wraz z Amd 1:2024 zawiera wymagania dla SZBI i może stanowić kryterium audytu.^[3] Wewnętrzny audyt zgodności z ISO/IEC 27001 nie jest tym samym co audyt certyfikacyjny.

ISO/IEC TS 27008:2019 zawiera wytyczne do przeglądu i oceny wdrożenia oraz działania zabezpieczeń bezpieczeństwa informacji, w tym technicznej oceny kontroli.^[16] Pozostaje opublikowana, ale jest w rewizji.

NIST SP 800-53A Rev. 5 zawiera konfigurowalne procedury oceny kontroli.^[4] Jest szczególnie przydatny wtedy, gdy potrzebna jest systematyczna ocena projektu, wdrożenia i działania określonych zabezpieczeń.

NIST CSF 2.0 porządkuje oczekiwane rezultaty zarządzania cyberbezpieczeństwem i może być używany do budowy profilu stanu obecnego i docelowego.^[5] Nie jest certyfikatem ani polskim obowiązkiem prawnym.

Mapowanie pomiędzy standardami może ograniczyć powtarzanie badań, ale nie tworzy automatycznej równoważności. Ten sam dowód może wspierać kilka wymagań, lecz każde wymaganie trzeba ocenić w jego własnym zakresie i kontekście.

Co rzeczywiście wynika z KRI

Na 29 sierpnia 2026 r. obowiązuje rozporządzenie Rady Ministrów z 21 maja 2024 r. w sprawie Krajowych Ram Interoperacyjności.^[6] ELI wskazuje, że akt utraci moc 23 lutego 2027 r.^[6]

§ 19 ust. 2 pkt 14 wymaga od podmiotów realizujących zadania publiczne zapewnienia okresowego audytu wewnętrznego w zakresie bezpieczeństwa informacji nie rzadziej niż raz na rok.^[6] Podstawa znajduje się w § 19, a nie w § 20. § 20 dotyczy rozliczalności i prowadzenia dzienników systemowych, w tym obowiązkowego rejestrowania określonych działań oraz, przy braku odrębnego przepisu, dwuletniego okresu przechowywania logów.^[6]

§ 19 ust. 3 przewiduje mechanizm, w którym wymagania ust. 1 i 2 uznaje się za spełnione, jeżeli SZBI opracowano na podstawie PN-ISO/IEC 27001, a ustanawianie zabezpieczeń, zarządzanie ryzykiem i audytowanie odbywa się na podstawie Polskich Norm związanych z tą normą, w tym PN-ISO/IEC 27002 i PN-ISO/IEC 27005.^[6] Nie jest to powszechny obowiązek posiadania certyfikatu ISO/IEC 27001.

W 2026 r. trwa proces przygotowania nowego rozporządzenia KRI, projekt RD313.^[17] Projekt przewiduje między innymi usunięcie z nowego KRI przepisów dotyczących SZBI, wskazując, że kwestie te zostały uregulowane w KSC. Na 29 sierpnia 2026 r. jest to jednak projekt, a nie obowiązujące prawo.^[17] Audyt KRI wykonywany w 2026 r. powinien opierać się na obowiązującym rozporządzeniu z 2024 r.

KSC po wdrożeniu NIS2

Nowelizacja KSC z 23 stycznia 2026 r. weszła zasadniczo w życie 3 kwietnia 2026 r.^[8] Aktualny tekst ujednolicony ustawy o krajowym systemie cyberbezpieczeństwa, według stanu Kancelarii Sejmu na 18 sierpnia 2026 r., powinien być podstawowym źródłem przy audycie prowadzonym pod koniec sierpnia 2026 r.^[7]

Art. 15 ust. 1 KSC stanowi, że podmiot kluczowy przeprowadza na własny koszt co najmniej raz na trzy lata audyt bezpieczeństwa systemu informacyjnego wykorzystywanego w procesie świadczenia usługi. Okres liczy się od dnia sporządzenia i podpisania raportu z ostatniego audytu.^[7] Podmiot kluczowy przekazuje kopię raportu właściwemu organowi do spraw cyberbezpieczeństwa w postaci elektronicznej w terminie trzech dni roboczych od jego otrzymania.^[7]

Organ właściwy do spraw cyberbezpieczeństwa może nakazać zewnętrzny audyt podmiotowi kluczowemu w każdym czasie, a podmiotowi ważnemu w przypadku wystąpienia incydentu poważnego albo innego naruszenia ustawy.^[7] Oznacza to, że regularny trzyletni audyt z art. 15 ust. 1 nie jest ogólnym obowiązkiem wszystkich podmiotów ważnych.

Art. 16 przewiduje, że podmiot kluczowy lub ważny realizuje obowiązki rozdziału 3 w terminie 12 miesięcy od dnia spełnienia przesłanek uznania za taki podmiot, a podmiot kluczowy zapewnia pierwszy audyt w terminie 24 miesięcy od tej daty.^[7] Dla podmiotów, które spełniały przesłanki w dniu wejścia nowelizacji w życie, art. 33 ustawy nowelizującej ustanawia odpowiednio 12 i 24 miesiące liczone od 3 kwietnia 2026 r.^[8] Przepisy przejściowe zawierają wyjątki, między innymi dla dotychczasowych operatorów usług kluczowych, którzy wykonali wcześniejszy audyt.^[8]

KSC szczegółowo reguluje również, kto może przeprowadzić ustawowy audyt KSC. Może to być właściwie akredytowana jednostka oceniająca zgodność, co najmniej dwóch audytorów spełniających warunki ustawowe albo właściwy CSIRT sektorowy, jeżeli jego audytorzy spełniają te warunki.^[7] Art. 15 ust. 2a wyłącza osobę, która w audytowanym podmiocie realizuje zadania z art. 8 oraz art. 9-13 albo realizowała je w ciągu roku przed rozpoczęciem audytu.^[7] To konkretny wymóg prawny, a nie tylko ogólna zasada bezstronności.

NIS2 należy traktować jako unijne tło regulacyjne i źródło modelu nadzoru. Art. 32 dyrektywy wymaga, aby właściwe organy mogły wobec podmiotów kluczowych stosować między innymi kontrole na miejscu, nadzór zdalny, regularne ukierunkowane audyty bezpieczeństwa, audyty doraźne i skany bezpieczeństwa.^[9] Dla polskiego podmiotu konkretne obowiązki trzeba jednak ustalać przede wszystkim z aktualnej KSC.

RODO: regularna ocena skuteczności, nie obowiązkowo "audyt raz w roku"

RODO nie ustanawia powszechnego obowiązku wykonywania audytu bezpieczeństwa IT raz w roku. Art. 32 ust. 1 lit. d wymaga natomiast, odpowiednio do ryzyka, procesu regularnego testowania, mierzenia i oceniania skuteczności technicznych i organizacyjnych środków bezpieczeństwa przetwarzania.^[10]

Audyt może być jednym z elementów tego procesu, ale nie jest jedyną dopuszczalną metodą. W zależności od ryzyka mogą być potrzebne przeglądy konfiguracji, testy odtworzeniowe, skanowanie podatności, testy penetracyjne, ćwiczenia incydentowe, ocena dostawców i inne formy weryfikacji.

W audycie RODO trzeba też oddzielać bezpieczeństwo od pełnej zgodności z rozporządzeniem. Test techniczny może dostarczyć dowodów dotyczących art. 32, ale sam nie oceni prawidłowości podstaw przetwarzania, obowiązków informacyjnych, retencji, praw osób czy transferów danych.

DORA i relacja z KSC

DORA stosuje się od 17 stycznia 2025 r. do podmiotów finansowych wskazanych w rozporządzeniu.^[11] Dla podmiotów innych niż mikroprzedsiębiorstwa ramy zarządzania ryzykiem ICT podlegają regularnemu audytowi wewnętrznemu zgodnie z planem audytu, a częstotliwość i przedmiot audytów mają być współmierne do ryzyka ICT.^[11]

DORA ustanawia również zaawansowane testy odporności TLPT. Obowiązek przeprowadzania TLPT co najmniej raz na trzy lata dotyczy podmiotów wskazanych zgodnie z art. 26, a nie każdego podmiotu objętego DORA.^[11] TLPT nie jest synonimem audytu SZBI ani zwykłego testu penetracyjnego.

Szczególnej uwagi wymaga relacja DORA z KSC. Art. 8i KSC stanowi, że do podmiotów kluczowych lub ważnych z sektora bankowości i infrastruktury rynków finansowych nie stosuje się części przepisów KSC dotyczących SZBI i zgłaszania poważnych incydentów, z katalogiem wyraźnie wskazanych wyjątków.^[7] Art. 15 nie został wymieniony w tym katalogu. Nie wolno więc mechanicznie zakładać, że podmiot finansowy objęty DORA ma dodatkowo wykonywać okresowy audyt KSC z art. 15 tylko dlatego, że spełnia przesłanki podmiotu kluczowego lub ważnego. Trzeba najpierw ustalić jego dokładny status sektorowy i zakres art. 8i.

Audyt zdalny, na miejscu czy hybrydowy

Nie istnieje wiarygodna uniwersalna proporcja typu "70% audytu można zrobić zdalnie". Formę badania dobiera się do potrzebnego dowodu i ryzyka.

Dokumenty, eksporty konfiguracji, logi, część wywiadów i wiele ustawień usług chmurowych można zwykle oceniać zdalnie. Wizyta na miejscu może być potrzebna przy zabezpieczeniach fizycznych, środowiskach odizolowanych, OT, magazynowaniu nośników, obserwacji rzeczywistego procesu albo wtedy, gdy zdalnie nie można uzyskać wystarczającego dowodu.

ISO 19011:2026 uwzględnia zmiany wynikające z technologii, cyfryzacji i środowisk wirtualnych oraz wzmacnia podejście oparte na ryzyku.^[1] Nie narzuca jednak procentowego podziału pracy ani jednej prawidłowej formy audytu.

Praca zdalna powinna odbywać się przez zatwierdzone kanały, na kontach imiennych, z minimalnymi uprawnieniami i odpowiednim rejestrowaniem dostępu. Jeżeli dowód może zostać zaprezentowany podczas kontrolowanej sesji, kopiowanie całej bazy lub konfiguracji do środowiska audytora często nie jest potrzebne.

Niezależność, kompetencje i poufność

Bezstronność nie oznacza, że audytor nigdy wcześniej nie mógł pracować dla organizacji. Trzeba ocenić konkretny konflikt: kto projektował zabezpieczenie, kto je wdrażał, kto je eksploatuje, kto zatwierdza wynik i czy wynagrodzenie zależy od rezultatu audytu.

Dla zwykłego audytu doradczego zasady niezależności wynikają z przyjętej metodyki, umowy i oczekiwanego poziomu pewności. Dla ustawowego audytu KSC obowiązują dodatkowe, konkretne warunki określone w art. 15, w tym wymagania wobec podmiotów i audytorów oraz roczne wyłączenie osób realizujących w podmiocie zadania z art. 8 oraz art. 9-13.^[7]

Przed zawarciem umowy warto sprawdzić doświadczenie zespołu w sektorze i badanych technologiach, sposób doboru próby, proces recenzji raportu, ochronę dowodów oraz zdolność do wykonania retestu. Certyfikat osobowy może potwierdzać określony zakres wiedzy, ale nie zastępuje doświadczenia ani nie usuwa konfliktu interesów.

Poufność jest szczególnie ważna, ponieważ dokumentacja audytowa może tworzyć gotową mapę słabości organizacji. Raporty, eksporty konfiguracji, wyniki skanów i materiały robocze powinny mieć ustaloną klasyfikację, odbiorców, miejsce przetwarzania, retencję i sposób bezpiecznego usunięcia.

Jak zamknąć ustalenie po audycie

Zamknięcie ustalenia nie powinno polegać na zmianie statusu w arkuszu z "otwarte" na "zamknięte". Potrzebny jest dowód, że przyczyna problemu została usunięta lub że zaakceptowano ryzyko na właściwym poziomie decyzyjnym.

Jeżeli ustalenie dotyczy braku MFA, dowodem może być konfiguracja, lista objętych kont i wynik testu. Jeżeli dotyczy podatności, potrzebny może być wynik ponownego skanowania albo testu. Jeżeli dotyczy niejasnej odpowiedzialności, zamknięcie wymaga nie tylko dokumentu, ale również przypisania roli i wdrożenia procesu.

Retest powinien być proporcjonalny do ustalenia. Nie zawsze trzeba ponownie wykonywać cały audyt. W przypadku problemu krytycznego warto jednak sprawdzić nie tylko samą poprawkę, ale także to, czy nie wprowadziła nowego ryzyka.