NIS 2 w praktyce: 7 najczęstszych błędów na starcie wdrożenia i jak ich uniknąć
NIS 2 nie jest „kolejną regulacją do odhaczenia” – to zmiana filozofii. Cyberbezpieczeństwo staje się zarządzanym ryzykiem biznesowym, z dużymi oczekiwaniami wobec kierownictwa, raportowania incydentów i nadzoru nad dostawcami. Choć Polska wciąż finalizuje wdrożenie dyrektywy, rynek już wymusza zgodność, szczególnie w łańcuchach dostaw. Przygotowaliśmy 7 najczęstszych błędów, które widzimy na starcie wraz z interpretacjami, przykładami i checklistami.
Dyrektywa NIS 2 zmienia zasady gry w obszarze cyberbezpieczeństwa, a tym samym – w zarządzaniu ryzykiem biznesowym. Wprawdzie termin transpozycji w UE minął 17 października 2024 r., ale polskie wdrożenie przez nowelizację KSC jeszcze się domykało (projekt był procedowany; rząd informował o przyjęciu projektu w październiku 2025). Firmy jednak nie mogą czekać. Rośnie m.in. presja ze strony klientów i partnerów w sektorach regulowanych, którzy pytają o NIS 2 na „tu i teraz”. W artykule pokazujemy, jakie błędy najczęściej pojawiają się na starcie i jak ich uniknąć.
„To nas nie dotyczy” – błędna samoidentyfikacja
Na czym polega błąd: Organizacja zakłada, że skoro jest MŚP albo nie jest infrastrukturą krytyczną, to NIS 2 jej nie obejmuje. Tymczasem NIS 2 rozszerza zakres sektorów i wprowadza logikę klasyfikacji podmiotów (kluczowe vs ważne), a dodatkowo presja łańcucha dostaw może objąć także mniejszych dostawców.
Objawy w organizacji:
- brak formalnej decyzji „jesteśmy/nie jesteśmy w NIS 2” wraz z uzasadnieniem;
- brak mapowania usług krytycznych i powiązanych systemów;
- brak właściciela obszaru cyberbezpieczeństwa (Compliance/ERM/CISO przerzuca na IT i odwrotnie).
Minicase (IT/outsourcing): Software house obsługujący systemy banku nie jest duży, ale klient wymaga ankiet bezpieczeństwa, MFA, backupów, procedur dot. incydentów i prawa do audytu, bo sam podlega ostrzejszym obowiązkom. Efekt? NIS 2 „wchodzi” drzwiami kontraktu.
Jak to naprawić (praktycznie):
- zrób szybką samoocenę: sektor/usługi, wielkość, rola w łańcuchu dostaw;
- spisz decyzję i ryzyka (to będzie tzw. dowód należytej staranności);
- jeżeli jesteś dostawcą regulowanych podmiotów, przygotuj tzw. pakiet zaufania, czyli polityki + dowody.
Checklista „30 minut”:
- Czy świadczymy usługę z sektorów objętych NIS 2 (wprost lub przez dostawy)?
- Czy mamy listę usług krytycznych i właścicieli biznesowych?
- Czy mamy dokument „stanowisko dot. NIS 2” podpisany przez zarząd i/lub compliance?
Zaczynamy od SIEM-a – technologia przed ryzykiem i procesem
Na czym polega błąd: Organizacja kupuje narzędzia (SIEM/EDR/XDR), zanim ustali, co chroni, przed kim, jaki ma apetyt na ryzyko i jakie procesy mają działać 24/7. NIS 2 wymaga wdrożenia adekwatnych środków zarządzania ryzykiem (organizacyjnych, operacyjnych i technicznych), a narzędzia powinny się pojawić dopiero, jak zidentyfikujemy obszary kluczowe.
Objawy w organizacji:
- sytuacja w rodzaju: „mamy system, ale nie mamy procedury”;
- docierają alerty, ale nikt nie wie, co robić i kto decyduje o eskalacji;
- brak metryk skuteczności i odpowiedzi na pytanie, czy nasze zabezpieczenia działają.
Jak to naprawić:
- zacznij od mapy ryzyka (usługi → procesy → systemy → dane → zależności);
- dopiero potem zdefiniuj minimalny „control set” (np. MFA, backup, logowanie podatności, EDR);
- wybierz narzędzia pod proces reagowania i raportowania.
Checklista „Najpierw proces”:
- Mamy zdefiniowane scenariusze incydentów (IT i OT).
- Mamy RACI: kto wykrywa, kto decyduje, kto raportuje.
- Mamy progi dla poważnego incydentu oraz ścieżkę eskalacji.
Shadow IT i brak inwentaryzacji – brak ochrony czegoś, czego nie widać
Na czym polega błąd: Organizacja nie ma pełnej wiedzy o zasobach: usługach chmurowych, systemach OT, aplikacjach SaaS kupowanych na kartę, kontach uprzywilejowanych, integracjach. W praktyce audyty zgodności (i potencjalne incydenty) najczęściej „rozjeżdżają się” właśnie na braku widoczności.
Minicase (sektor publiczny): Jednostka ma wdrożone MFA w systemie głównym, ale integracja raportowa jest utrzymywana na starym koncie serwisowym bez MFA i bez rotacji hasła. Atak wykonany jest bokiem, a potem nie ma nawet logów, żeby szybko ustalić zakres.
Jak to naprawić:
- utwórz bazę CMDB light: krytyczne usługi i ich komponenty (nie musisz mieć od razu perfekcyjnej bazy CMDB);
- wymuś rejestr SaaS i integracji (proces zakupowy + IT);
- ustandaryzuj konta serwisowe, uprawnienia i logowanie zdarzeń.
Checklista „Widoczność”:
- Lista krytycznych aktywów (IT/OT) + właściciele.
- Lista kont uprzywilejowanych i serwisowych + zasady rotacji.
- Minimalny standard logowania (co, gdzie, jak długo).
Raportowanie 24 h/72 h „na papierze” – bez dyżurów, decyzji i gotowych szablonów
Na czym polega błąd: Organizacja ma procedurę, ale nie jest w stanie jej wykonać w realnym czasie, szczególnie w oknie 24 godzin na wczesne ostrzeżenie i 72 godziny na pełne zgłoszenie.
Objawy:
- nie ma ustalonego trybu działania poza godzinami pracy;
- nie wiadomo, kto ma prawo wysłać zgłoszenie do CSIRT i na jakiej podstawie;
- brak szablonów, brak „Minimum Viable Report”.
Jak to naprawić:
- zdefiniuj dyżur decyzyjny (niekoniecznie pełen SOC – czasem wystarczy na telefon + usługa zewnętrzna);
- przygotuj 2 szablony raportów do zgłoszeń 24 h i 72 h;
- przećwicz raportowanie na przykładzie ataków typu: ransomware, wyciek danych (RODO), awaria systemu OT.
Checklista „Raport w 60 minut”:
- Jednoznaczna definicja „poważnego incydentu” w organizacji.
- Lista kontaktów + zastępstwa + kanał awaryjny.
- Szablony 24h/72h + wymagane załączniki.
Dostawcy traktowani jak formalność – brak twardych zapisów w umowach
Na czym polega błąd: Vendor risk management kończy się na ankiecie w Excelu. A NIS 2 mocno akcentuje bezpieczeństwo łańcucha dostaw i zależności.
Minicase (infrastruktura/OT): Operator zleca zdalny serwis OT firmie zewnętrznej. Dostawca ma dostęp uprzywilejowany, ale bez wymogu MFA i bez ograniczeń czasowych sesji. Incydent zaczyna się od kompromitacji dostawcy.
Jak to naprawić:
- segmentuj dostawców na krytyczni/ważni/pozostali po ich wpływie na usługę;
- w umowach wprowadź minimum wymagań: MFA, logowanie, zgłaszanie incydentów, SLA bezpieczeństwa, prawo do audytu, wymagania dot. podwykonawców;
- zbieraj dowody (nie deklaracje!): raporty z testów, certyfikaty, wyniki skanów/pentestów.
Checklista „Klauzule must-have”:
- Obowiązek zgłoszenia incydentu w określonym czasie.
- MFA/IAM/PAM dla dostępu zdalnego i kont uprzywilejowanych.
- Prawo do audytu / raportów + zasady podwykonawców.
Zarząd w tle – brak governance i nadzoru, który da się udowodnić
Na czym polega błąd: Stwierdzenie, że temat cyber jest w IT, a zarząd dowiaduje się przy okazji budżetu. Tymczasem NIS 2 wzmacnia odpowiedzialność kierownictwa za zatwierdzenie i nadzór nad środkami zarządzania ryzykiem. W polskim projekcie nowelizacji KSC szeroko komentowane są również mechanizmy sankcyjne i oczekiwania wobec kadry zarządzającej (w tym potencjalne kary osobiste, zależnie od ostatecznego brzmienia przepisów).
Jak to naprawić:
- stwórz cykliczny rytm governance: kwartalny przegląd ryzyk cyberbezpieczeństwa, incydentów, KPI;
- zapewnij szkolenia C-level (to nie ma być tylko higiena haseł, ale analiza ryzyka (BIA), decyzje, odpowiedzialność, ciągłość działania);
- prowadź rejestr decyzji: co akceptujemy, co redukujemy, co przenosimy (np. ubezpieczenie).
Checklista „Board-ready”:
- 1-stronicowy dashboard ryzyk cyber (KRI + trendy).
- Protokół decyzji i zatwierdzeń (budżet, priorytety, wyjątki).
- Plan szkoleń i ćwiczeń (zarząd + kluczowe role).
„Zrobimy wdrożenie ISO 27001 i będzie po temacie” – mylenie standardu ISO z obowiązkiem prawnym NIS 2
Na czym polega błąd: Organizacja zakłada, że certyfikacja ISO 27001 automatycznie załatwia temat NIS 2. W praktyce ISO 27001 bardzo pomaga (mapowanie kontroli, podejście oparte o ryzyko), ale NIS 2 dokłada elementy specyficzne, np. sztywne terminy raportowania, oczekiwania nadzorcze, nacisk na łańcuch dostaw i operacyjność.
Jak to naprawić (najprościej):
- wykonaj mapowanie: NIS 2 (wymagania) → obecne kontrole (ISO/ITSM/BCM) → luki → plan działań;
- ustal kolejność wdrożeń: quick wins (MFA, backup testowany, inwentaryzacja) vs projekty długie (SOC, IAM, segmentacja OT);
- przygotuj pakiet ewidencyjny na potrzeby audytu/nadzoru.
Checklista „Mapowanie w 2 tygodnie”:
- Macierz wymagań NIS 2 vs kontrole/audyty ISO27001.
- Lista luk + właściciele biznesowi + terminy.
- Repozytorium dowodów (polityki, logi, raporty z testów, protokoły ćwiczeń).
Podsumowanie. Jak zacząć, żeby nie utknąć po 3 miesiącach?
Najlepszy pakiet startowy z NIS 2 to nie zakup narzędzia, to trójkąt: klasyfikacja → ryzyka, proces → dowody.
Jeśli dopiero zaczynasz, zrób to w kolejności:
- Samoidentyfikacja i mapa usług krytycznych.
- Analiza luki pod środki zarządzania ryzykiem.
- Budowa procedur, SZBI.
- Szybkie wdrożenia wynikające z identyfikacji obszarów kluczowych (MFA, backup, inwentaryzacja, łańcuch dostaw).
- Procedura obsługi incydentu realna w czasie 24 h/72 h, wyznaczona osoba do kontaktu z CSIRT.
- Wsparcie top management i ustalenie rytmu zarządczego.
O Autorze
