Audyt NIS2 nie zaczyna się od zakupu firewalla ani od napisania kilkudziesięciu polityk bezpieczeństwa. Najpierw trzeba ustalić trzy rzeczy: czy organizacja podlega ustawie o krajowym systemie cyberbezpieczeństwa, które procesy i systemy są krytyczne oraz jak duża jest różnica między stanem obecnym a wymaganym.
W Polsce NIS2 została wdrożona nowelizacją ustawy o krajowym systemie cyberbezpieczeństwa, która weszła w życie 3 kwietnia 2026 roku. Podmioty spełniające kryteria w dniu wejścia przepisów w życie mają co do zasady czas do 3 października 2026 roku na wpis do Wykazu KSC oraz do 3 kwietnia 2027 roku na wdrożenie głównych obowiązków i podłączenie do systemu S46. W przypadku części podmiotów kluczowych pierwszy obowiązkowy audyt trzeba przeprowadzić do 3 kwietnia 2028 roku, a następne co najmniej raz na trzy lata.
To oznacza, że rok 2026 nie jest już okresem oczekiwania na ustawę. Jest etapem wdrożenia.
Executive Summary dla zarządu
Audyt zgodności z NIS2 powinien dać zarządowi odpowiedź na pięć konkretnych pytań:
- Czy firma jest podmiotem kluczowym, podmiotem ważnym albo dostawcą, od którego kontrahenci będą wymagać standardów zgodnych z NIS2?
- Które procesy biznesowe zależą od systemów IT, OT, usług chmurowych i dostawców zewnętrznych?
- Jakie zabezpieczenia są wdrożone, czy rzeczywiście działają i czy można przedstawić dowody ich stosowania?
- Które luki stwarzają największe ryzyko przerwania działalności albo naruszenia obowiązków ustawowych?
- Jaki jest koszt, priorytet i termin usunięcia każdej istotnej niezgodności?
Najpoważniejszym błędem jest potraktowanie NIS2 jako projektu działu IT. Odpowiedzialność za zatwierdzanie środków zarządzania ryzykiem i nadzorowanie ich wdrożenia spoczywa na kierownictwie organizacji. Polskie przepisy przewidują odpowiedzialność kierowników za realizację zadań z zakresu cyberbezpieczeństwa, a wobec kierownika podmiotu kluczowego możliwy jest również tymczasowy zakaz pełnienia funkcji zarządczych.
Dział IT może skonfigurować MFA, segmentację sieci i system monitorowania zdarzeń. Nie może jednak samodzielnie zaakceptować ryzyka biznesowego, ustalić maksymalnego dopuszczalnego czasu przestoju produkcji ani zatwierdzić budżetu na odtworzenie infrastruktury. To są decyzje zarządcze.
Kogo obejmuje NIS2 i co zmienia status podmiotu kluczowego lub ważnego?
Nowelizacja ustawy o KSC obejmuje znacznie więcej organizacji niż wcześniejsze regulacje. Ministerstwo Cyfryzacji szacuje, że w systemie może znaleźć się około 38 tys. podmiotów, w tym około 27 tys. jednostek publicznych.
Do sektorów objętych regulacją należą między innymi:
- energetyka, ciepłownictwo, gaz i paliwa,
- transport drogowy, kolejowy, lotniczy i wodny,
- bankowość i infrastruktura rynków finansowych,
- ochrona zdrowia i produkcja wyrobów medycznych,
- wodociągi, kanalizacja i gospodarowanie odpadami,
- infrastruktura cyfrowa, centra danych, chmura i usługi zarządzane,
- administracja publiczna,
- usługi pocztowe i kurierskie,
- produkcja chemikaliów, żywności, maszyn, elektroniki i środków transportu,
- dostawcy usług cyfrowych oraz wybrane podmioty badawcze.
Sama obecność na tej liście nie zawsze przesądza o kwalifikacji. Trzeba sprawdzić jednocześnie sektor, rodzaj świadczonej usługi, wielkość przedsiębiorstwa, strukturę grupy kapitałowej oraz wyjątki ustawowe. Standardowe kryterium wielkości obejmuje przede wszystkim średnie i duże przedsiębiorstwa, ale niektóre podmioty mogą zostać objęte regulacją niezależnie od liczby pracowników lub wysokości obrotu.
Nie należy automatycznie przyjmować, że próg wynosi po prostu „50 pracowników albo 10 mln euro obrotu”. Klasyfikacja wielkości przedsiębiorstwa uwzględnia również sumę bilansową, relacje partnerskie i powiązania kapitałowe. Firma zatrudniająca 35 osób może przekroczyć próg po doliczeniu danych podmiotów powiązanych.
Podmiot kluczowy a podmiot ważny
Zakres podstawowych obowiązków jest zbliżony. Obie grupy muszą między innymi zarządzać ryzykiem, wdrożyć odpowiednie zabezpieczenia, obsługiwać incydenty, prowadzić dokumentację i kontrolować łańcuch dostaw.
Różnica dotyczy przede wszystkim modelu nadzoru:
- podmioty kluczowe podlegają nadzorowi ex ante i ex post – organ może działać prewencyjnie, także bez wcześniejszego incydentu lub potwierdzonego naruszenia;
- podmioty ważne podlegają zasadniczo nadzorowi ex post – działania nadzorcze są podejmowane po uzyskaniu informacji wskazujących na potencjalną niezgodność.
W praktyce podmiot kluczowy musi zakładać możliwość kontroli dokumentacji, audytu bezpieczeństwa, inspekcji, żądania danych i weryfikacji technicznej niezależnie od tego, czy wcześniej doszło do poważnego ataku.
Podmiot ważny nie powinien jednak traktować nadzoru ex post jako taryfy ulgowej. Poważny incydent, skarga klienta, informacja od CSIRT, wynik kontroli dostawcy albo brak wymaganego zgłoszenia mogą uruchomić szczegółową kontrolę.
Odpowiedzialność zarządu nie kończy się na zatwierdzeniu polityki
Kierownictwo powinno:
- zatwierdzić środki zarządzania ryzykiem,
- nadzorować ich wdrożenie,
- uczestniczyć w szkoleniach z cyberbezpieczeństwa,
- otrzymywać regularne informacje o ryzyku i incydentach,
- podejmować udokumentowane decyzje dotyczące akceptacji ryzyka,
- zapewnić zasoby finansowe i organizacyjne potrzebne do realizacji obowiązków.
Brak budżetu nie jest zabezpieczeniem przed odpowiedzialnością. Jeżeli zarząd wie, że kopie zapasowe nie są testowane, system produkcyjny nie ma wsparcia producenta, a konta administratorów działają bez MFA, powinien podjąć decyzję naprawczą albo formalnie przeanalizować i udokumentować ryzyko. Milczenie w protokole zarządu nie usuwa problemu.
Dyrektywa NIS2 przewiduje maksymalny poziom administracyjnych kar pieniężnych dla podmiotów kluczowych wynoszący co najmniej 10 mln euro albo 2% całkowitego rocznego światowego obrotu, zależnie od tego, która wartość jest wyższa. Dla podmiotów ważnych jest to co najmniej 7 mln euro albo 1,4% obrotu. Szczegółowy mechanizm nakładania kar wynika z przepisów krajowych.
Kara finansowa jest tylko jednym ze skutków. Koszt incydentu obejmuje również przestój, odtworzenie środowiska, pracę informatyków i ekspertów zewnętrznych, obsługę prawną, utracone zamówienia oraz roszczenia kontrahentów.
Jak wygląda profesjonalny audyt NIS2 i Gap Analysis?
Samo zestawienie komputerów, serwerów i licencji jest potrzebne, ale nie stanowi audytu zgodności. To jeden z elementów Asset Management, czyli zarządzania zasobami IT i OT.
Profesjonalny audyt NIS2 jest analizą luk pomiędzy wymaganym a faktycznym poziomem zabezpieczeń. Powinien obejmować dokumentację, procesy, ludzi, technologię, obiekty fizyczne i dostawców. Jego wynikiem nie może być wyłącznie lista niezgodności. Zarząd potrzebuje oceny ryzyka, priorytetów, właścicieli działań, terminów oraz szacowanych kosztów.
Metodykę można oprzeć na wymaganiach ustawy i dyrektywy NIS2, a pomocniczo między innymi na:
- ISO/IEC 27001 i ISO/IEC 27002 – w zakresie systemu zarządzania bezpieczeństwem informacji i katalogu zabezpieczeń,
- ISO 22301 – w zakresie ciągłości działania,
- ISO/IEC 27005 – w zakresie zarządzania ryzykiem bezpieczeństwa informacji,
- NIST Cybersecurity Framework 2.0 – przy ocenie funkcji Govern, Identify, Protect, Detect, Respond i Recover,
- IEC 62443 – w organizacjach korzystających z przemysłowych systemów sterowania i infrastruktury OT,
- dyrektywie CER – gdy organizacja jest również podmiotem krytycznym i musi łączyć cyberbezpieczeństwo z odpornością fizyczną.
Certyfikat ISO 27001 może ułatwić wdrożenie, ale nie daje automatycznej zgodności z NIS2. Zakres certyfikacji bywa węższy niż zakres działalności objętej ustawą, a audyt certyfikacyjny nie zawsze obejmuje wszystkie ustawowe obowiązki, terminy zgłaszania incydentów i relacje z CSIRT.
Faza 1: ocena dokumentacji, odpowiedzialności i procesów
Audytor ustala najpierw zakres organizacyjny i prawny. Sprawdza między innymi:
- wynik kwalifikacji podmiotu,
- zakres usług objętych ustawą,
- strukturę odpowiedzialności zarządu, CISO, IT, compliance i właścicieli procesów,
- politykę bezpieczeństwa oraz metodykę zarządzania ryzykiem,
- rejestr aktywów i właścicieli zasobów,
- klasyfikację informacji,
- procedury zarządzania incydentami,
- plany Business Continuity i Disaster Recovery,
- zasady zarządzania zmianą, podatnościami i aktualizacjami,
- procedury dotyczące dostawców,
- program szkoleń i testów świadomości,
- wyniki wcześniejszych audytów, testów penetracyjnych i ćwiczeń odtworzeniowych.
Dokument istniejący tylko na dysku działu compliance nie jest dowodem działania procesu. Jeżeli polityka wymaga kwartalnego przeglądu uprawnień, audytor powinien zobaczyć raporty z przeglądów, decyzje właścicieli systemów i potwierdzenia odebrania dostępów.
Faza 2: weryfikacja techniczna środowiska IT i OT
Weryfikacja techniczna powinna potwierdzić, czy deklarowane zabezpieczenia są wdrożone i skuteczne. Zakres zależy od ryzyka, ale zwykle obejmuje:
- kompletność ewidencji urządzeń, systemów, aplikacji, kont i usług chmurowych,
- konfigurację MFA, w szczególności dla administratorów, poczty, VPN i paneli chmurowych,
- podział kont standardowych i uprzywilejowanych,
- cykliczne przeglądy uprawnień i automatyczne blokowanie kont byłych pracowników,
- segmentację sieci użytkowników, serwerów, gości, urządzeń IoT oraz środowiska OT,
- szyfrowanie danych w transmisji i w spoczynku,
- zarządzanie kluczami kryptograficznymi,
- centralne logowanie zdarzeń, retencję logów i monitoring przez SIEM lub usługę SOC,
- zarządzanie podatnościami i czas usuwania luk krytycznych,
- stan wsparcia systemów operacyjnych, urządzeń sieciowych i oprogramowania przemysłowego,
- działanie systemów EDR/XDR,
- zabezpieczenie poczty elektronicznej, między innymi SPF, DKIM i DMARC,
- kopie zapasowe odporne na skasowanie lub zaszyfrowanie,
- wyniki próbnego odtworzenia danych i całych usług,
- zabezpieczenia zdalnego dostępu dostawców do sieci OT.
W praktyce dużo problemów pojawia się nie na stacjach roboczych, lecz na styku środowisk. Przykładem jest serwer pośredniczący między systemem ERP a linią produkcyjną, który nie ma wyznaczonego właściciela, nie trafia do standardowego procesu aktualizacji i działa na niewspieranym systemie operacyjnym.
Zero Trust nie powinien być w raporcie audytowym pustym hasłem. Wymaga konkretnych mechanizmów: weryfikacji tożsamości, minimalnych uprawnień, kontroli stanu urządzenia, ograniczania ruchu sieciowego, rejestrowania dostępu i ponownej oceny zaufania podczas sesji. Nie każda firma musi od razu kupować rozbudowaną platformę Zero Trust Network Access. Często najpierw trzeba uporządkować Active Directory, konta uprzywilejowane i reguły zapory.
Faza 3: analiza ryzyka i łańcucha dostaw
Audyt powinien łączyć podatności techniczne z konsekwencjami biznesowymi. Brak aktualizacji na urządzeniu testowym ma inne znaczenie niż ta sama luka na bramie VPN obsługującej dostęp administratorów do produkcji.
Dla każdego istotnego ryzyka należy określić:
- zagrożenie i możliwy scenariusz,
- podatny proces, zasób lub dostawcę,
- prawdopodobieństwo,
- skutek finansowy, operacyjny, prawny i reputacyjny,
- obecne zabezpieczenia,
- ryzyko rezydualne,
- rekomendowane działanie,
- właściciela ryzyka,
- termin realizacji,
- sposób weryfikacji skuteczności.
Osobnym obszarem jest Third-Party Risk Management, czyli zarządzanie ryzykiem dostawców. Sama ankieta wysłana raz przy podpisaniu umowy nie wystarcza.
Dostawców należy podzielić według krytyczności. Najwyższy poziom powinien obejmować podmioty, które:
- przetwarzają wrażliwe lub kluczowe dane,
- mają uprzywilejowany dostęp do infrastruktury,
- utrzymują systemy niezbędne do świadczenia usług,
- dostarczają komponenty do środowiska produkcyjnego,
- nie mogą zostać szybko zastąpione.
Dla dostawców krytycznych warto weryfikować raporty z audytów, certyfikaty wraz z ich zakresem, wyniki testów bezpieczeństwa, procedury zgłaszania incydentów, lokalizację przetwarzania danych, stosowanie podwykonawców i czas odtworzenia usługi.
Umowa powinna określać co najmniej:
- obowiązek szybkiego zgłoszenia incydentu,
- wymagane parametry bezpieczeństwa,
- prawo do audytu lub otrzymania niezależnego raportu,
- zasady zarządzania podatnościami i aktualizacjami,
- wymagania dotyczące dostępu zdalnego,
- warunki korzystania z dalszych podwykonawców,
- dostępność kopii danych i procedurę ich zwrotu,
- wsparcie podczas dochodzenia i raportowania incydentu,
- zasady zakończenia współpracy.
Najtrudniejszy przypadek to dostawca krytyczny, który odmawia udostępnienia informacji bezpieczeństwa i nie akceptuje klauzul audytowych. Nie zawsze można go natychmiast wymienić. Wtedy ryzyko trzeba formalnie zarejestrować, wprowadzić zabezpieczenia kompensacyjne i przygotować plan migracji.
Plan naprawczy po audycie: co wdrażać najpierw?
Raport zawierający 80 rekomendacji bez kolejności realizacji jest mało użyteczny. Priorytet powinien zależeć od wpływu na krytyczne usługi, możliwości wykorzystania luki oraz czasu potrzebnego na wdrożenie zabezpieczenia.
Priorytet 1: usuń ryzyka mogące zatrzymać działalność lub uniemożliwić reakcję
Do tej grupy zwykle należą:
- brak działających i przetestowanych kopii zapasowych,
- brak MFA na kontach administracyjnych i dostępie zdalnym,
- niewspierane systemy wystawione do internetu,
- jeden współdzielony login administratora,
- brak procedury i danych kontaktowych do zgłoszenia incydentu,
- brak segmentacji między siecią biurową, gościnną i produkcyjną,
- niekontrolowany zdalny dostęp serwisów zewnętrznych,
- brak monitorowania kluczowych serwerów i urządzeń brzegowych.
Backup należy oceniać przez możliwość odtworzenia procesu, a nie liczbę wykonanych kopii. Firma może mieć codzienne kopie bazy ERP, lecz nadal nie być w stanie uruchomić sprzedaży, jeżeli nie zachowuje konfiguracji aplikacji, certyfikatów, dokumentacji integracji i infrastruktury tożsamościowej.
Dla najważniejszych procesów trzeba ustalić:
- RTO, czyli maksymalny zakładany czas odtworzenia,
- RPO, czyli dopuszczalną utratę danych mierzoną czasem,
- minimalny skład zespołu potrzebny do pracy awaryjnej,
- zależności od energii, telekomunikacji, chmury i dostawców,
- kolejność uruchamiania systemów.
Priorytet 2: zbuduj zdolność wykrywania i zgłaszania incydentów
NIS2 wprowadza trzy główne etapy raportowania poważnego incydentu:
- Wczesne ostrzeżenie w ciągu 24 godzin od uzyskania wiedzy o poważnym incydencie.
- Zgłoszenie incydentu w ciągu 72 godzin, zawierające aktualizację informacji, wstępną ocenę zdarzenia, jego powagę, wpływ oraz – gdy jest to możliwe – wskaźniki kompromitacji.
- Raport końcowy nie później niż miesiąc po zgłoszeniu, obejmujący szczegółowy opis incydentu, jego przyczynę, zastosowane środki zaradcze i ewentualny wpływ transgraniczny. Gdy incydent nadal trwa, składany jest raport z postępu, a raport końcowy po jego obsłużeniu.
Nie jest to wyłącznie zadanie administratora. Procedura powinna określać role co najmniej dla zespołu technicznego, bezpieczeństwa, zarządu, działu prawnego, ochrony danych, komunikacji i właściciela dotkniętej usługi.
Dobrze przygotowany plan reagowania zawiera:
- kryteria uznania zdarzenia za incydent poważny,
- ścieżkę eskalacji działającą poza godzinami pracy,
- dane kontaktowe właściwego CSIRT i organu sektorowego,
- zasady zabezpieczania logów i innych dowodów,
- gotowe formularze raportów 24-godzinnego i 72-godzinnego,
- reguły komunikacji z klientami i mediami,
- zasady współpracy z ubezpieczycielem i zewnętrzną firmą incident response,
- relację między zgłoszeniem NIS2 a zgłoszeniem naruszenia danych do Prezesa UODO.
Terminy NIS2 i RODO mogą biec równolegle, ale dotyczą innych obowiązków. Zgłoszenie do CSIRT nie zastępuje zgłoszenia naruszenia ochrony danych osobowych.
Priorytet 3: uporządkuj SZBI i dowody działania zabezpieczeń
System Zarządzania Bezpieczeństwem Informacji nie powinien być segregatorem przygotowanym przed kontrolą. Musi tworzyć powtarzalny cykl:
- identyfikacja zasobów i procesów,
- szacowanie ryzyka,
- dobór zabezpieczeń,
- przypisanie odpowiedzialności,
- monitorowanie,
- audyty i przeglądy,
- działania korygujące,
- raportowanie do kierownictwa.
Najczęstszą luką nie jest całkowity brak zabezpieczenia, lecz brak dowodu jego regularnego stosowania. Firma deklaruje kwartalne testy odtworzeniowe, lecz ostatni test przeprowadzono dwa lata wcześniej. Procedura wymaga odebrania dostępów w dniu zakończenia współpracy, ale konto byłego administratora nadal jest aktywne. Takie niezgodności są łatwe do wykazania podczas kontroli.
Jak powinien wyglądać końcowy raport z audytu?
Raport powinien zawierać:
- podstawę prawną i zakres audytu,
- opis metodyki,
- wynik kwalifikacji organizacji,
- ocenę dojrzałości poszczególnych obszarów,
- rejestr niezgodności i ryzyk,
- dowody potwierdzające ustalenia,
- rekomendacje techniczne i organizacyjne,
- plan działań na 30, 90, 180 i 365 dni,
- szacowany koszt działań,
- właścicieli poszczególnych zadań,
- ryzyka wymagające formalnej decyzji zarządu.
Skala dojrzałości powinna odróżniać przynajmniej proces nieistniejący, działania doraźne, proces powtarzalny, proces udokumentowany, proces mierzony oraz proces doskonalony. Sama odpowiedź „spełnia/nie spełnia” jest zbyt płaska, aby przygotować racjonalny plan inwestycji.
Pierwszym działaniem po audycie powinno być zatwierdzenie przez zarząd listy ryzyk krytycznych i właścicieli działań. Pisanie kolejnych polityk należy odłożyć, jeżeli firma nadal nie potrafi odtworzyć systemu sprzedażowego, nie kontroluje kont administratorów albo nie wykrywa logowania do infrastruktury z nietypowej lokalizacji.
Umów bezpłatną konsultację techniczną
FAQ: najczęstsze pytania o audyt NIS2
Ile czasu ma firma na zgłoszenie incydentu w ramach NIS2?
Wczesne ostrzeżenie należy przekazać w ciągu 24 godzin od uzyskania wiedzy o poważnym incydencie, a właściwe zgłoszenie w ciągu 72 godzin. Raport końcowy składa się zasadniczo w ciągu miesiąca od zgłoszenia.
Czy audyt NIS2 wymaga certyfikacji ISO 27001?
Nie. ISO/IEC 27001 jest przydatnym punktem odniesienia i może ograniczyć liczbę luk, ale certyfikat nie jest automatycznym potwierdzeniem zgodności z ustawą. Trzeba sprawdzić zakres certyfikacji oraz dodatkowe wymagania NIS2, zwłaszcza dotyczące incydentów, zarządu i łańcucha dostaw.
Kto odpowiada za wdrożenie NIS2: zarząd czy dział IT?
Za działania operacyjne odpowiadają wyznaczone zespoły, ale kierownictwo zatwierdza środki zarządzania ryzykiem i nadzoruje ich wdrożenie. Zarząd nie może przenieść całej odpowiedzialności na administratora, CISO ani zewnętrzną firmę informatyczną.
Czym różni się podmiot kluczowy od podmiotu ważnego?
Podstawowa różnica dotyczy nadzoru. Podmioty kluczowe mogą być kontrolowane prewencyjnie i następczo, natomiast wobec podmiotów ważnych nadzór ma zasadniczo charakter ex post, po pojawieniu się przesłanek wskazujących na niezgodność.
Czy każda firma zatrudniająca ponad 50 osób podlega NIS2?
Nie. Wielkość jest tylko jednym z kryteriów. Firma musi również działać w sektorze lub świadczyć usługę objętą ustawą, chyba że zostanie zakwalifikowana na podstawie szczególnych przepisów niezależnie od rozmiaru.
Czy mały dostawca usług IT może zostać objęty wymaganiami NIS2?
Może nie podlegać ustawie bezpośrednio, ale klienci objęci NIS2 będą wymagać od niego zabezpieczeń, zgłaszania incydentów, prawa do audytu i kontroli podwykonawców. Brak spełnienia tych warunków może oznaczać utratę kontraktu.
Jak długo trwa audyt zgodności z NIS2?
W średniej organizacji analiza dokumentacji, wywiady, próbki techniczne i przygotowanie raportu zajmują zwykle od kilku do kilkunastu tygodni. Zakres rośnie, gdy firma ma wiele lokalizacji, rozbudowane OT, dużą liczbę spółek albo niekompletną dokumentację.
Czy test penetracyjny wystarczy jako audyt NIS2?
Nie. Test penetracyjny bada wybrany fragment zabezpieczeń technicznych. Audyt NIS2 obejmuje dodatkowo zarządzanie ryzykiem, odpowiedzialność kierownictwa, ciągłość działania, obsługę incydentów, bezpieczeństwo dostawców, szkolenia i dokumentację.
Od czego firma powinna zacząć przygotowania?
Najpierw od formalnej kwalifikacji, określenia zakresu systemów objętych regulacją i przeprowadzenia Gap Analysis. Następnie należy usunąć ryzyka krytyczne: niesprawne backupy, brak MFA, niewspierane systemy, niekontrolowane konta uprzywilejowane i brak procedury raportowania incydentów.
Czy można zagwarantować pełną zgodność z NIS2?
Można wykazać wdrożenie wymaganych procesów i zabezpieczeń adekwatnych do ryzyka, ale nie da się zagwarantować braku incydentów. Celem jest ograniczenie prawdopodobieństwa i skutków ataku oraz możliwość udowodnienia, że organizacja zarządza ryzykiem w sposób świadomy, proporcjonalny i udokumentowany.
Autor: Krystian Walo – IT Administrator focused on Cybersecurity.
[ Treść sponsorowana ]
