NIS2 a IT – co trzeba wdrożyć w firmie i od czego zacząć?

1. Sprawdź, czy przepisy dotyczą Twojej firmy

Pierwszym krokiem jest ustalenie, czy organizacja spełnia kryteria podmiotu kluczowego lub ważnego w rozumieniu ustawy o krajowym systemie cyberbezpieczeństwa (KSC), wdrażającej NIS2 w Polsce. Znaczenie mają m.in. sektor i rodzaj działalności, wielkość przedsiębiorstwa oraz inne przesłanki określone w ustawie.

To przede wszystkim kwestia prawna i organizacyjna, a nie decyzja działu IT. Jeżeli nie masz pewności, czy firma podlega KSC, warto zacząć od analizy prawnej i compliance. W przypadku podmiotów spełniających kryteria ustawa przewiduje również obowiązek zgłoszenia do wykazu.

2. Ustal, jakie wymagania dotyczą Twojej firmy

NIS2 obejmuje m.in. zarządzanie ryzykiem, bezpieczeństwo systemów i informacji, incydenty, ciągłość działania, backup, łańcuch dostaw, podatności, kontrolę dostępu, zarządzanie aktywami, kryptografię oraz cyberhigienę i szkolenia.

Nie oznacza to jednak obowiązku wdrożenia konkretnego narzędzia dla każdego z tych obszarów. Sposób realizacji wymagań powinien wynikać z oceny ryzyka i specyfiki organizacji.

Część wymagań nie jest też zadaniem IT. Dotyczy m.in. odpowiedzialności zarządu, zarządzania ryzykiem, procedur i formalnych procesów związanych z bezpieczeństwem i incydentami. IT odpowiada natomiast za przełożenie odpowiednich ustaleń na działające środowisko technologiczne.

3. Sprawdź, gdzie jesteś dzisiaj

Kiedy wiadomo już, jakie wymagania dotyczą firmy, trzeba ocenić obecny stan organizacji i poziom ryzyka.

W praktyce warto przeanalizować m.in. wykorzystywane systemy, serwery, urządzenia i usługi, dostęp do danych, zabezpieczenia kont użytkowników i administratorów, aktualizacje, backup, monitoring, bezpieczeństwo sieci, dostęp zdalny oraz środowiska chmurowe. Warto również sprawdzić zależności od kluczowych dostawców i scenariusze awarii najważniejszych systemów.

To moment na ocenę ryzyka i analizę luk (gap analysis). Takie rozpoznanie bywa określane jako „audyt zerowy”, ale nie jest to formalny termin NIS2 ani ustawowy etap. Wynikiem powinno być wskazanie luk, związanych z nimi ryzyk oraz priorytetów dalszych działań.

Ocena techniczna infrastruktury nie zastępuje analizy prawnej ani obowiązkowego audytu. Podmioty kluczowe podlegają audytowi co najmniej raz na trzy lata, przy czym terminy pierwszego audytu zależą od ich statusu i wcześniejszych obowiązków audytowych.

W praktyce proces można więc podzielić na trzy uzupełniające się obszary:

Prawo i compliance → jakie obowiązki dotyczą firmy?

Ocena ryzyka i analiza luk → jaki jest obecny stan i czego brakuje?

IT → jak przełożyć wymagania i rekomendacje na konkretne rozwiązania?

NIS2 – podstawowe informacje. Przeczytaj nasz artykuł

1. Zarządzanie dostępem

Trzeba uporządkować, kto ma dostęp do systemów i danych oraz w jakim zakresie. W praktyce oznacza to m.in. przegląd uprawnień, zabezpieczenie kont administracyjnych, MFA, ograniczenie dostępu uprzywilejowanego i bezpieczny dostęp zdalny.

Kontrola dostępu i zarządzanie aktywami to jedne z obszarów objętych wymaganiami NIS2/KSC.

2. Bezpieczeństwo komputerów, serwerów i urządzeń

Firma powinna wiedzieć, jakie urządzenia i systemy wykorzystuje oraz czy są odpowiednio zabezpieczone. W praktyce oznacza to m.in. ochronę endpointów i serwerów, aktualizacje, bezpieczną konfigurację, ograniczenie zbędnych usług i uprawnień, szyfrowanie oraz kontrolę dostępu administracyjnego.

Liczy się nie tylko posiadanie zabezpieczeń, ale także ich prawidłowa konfiguracja i utrzymanie.

3. Aktualizacje i zarządzanie podatnościami

Nieaktualne oprogramowanie może zawierać znane podatności, zwiększające ryzyko incydentu. Warto mieć uporządkowany proces:

wykrycie podatności → ocena ryzyka → priorytet → aktualizacja lub inne działanie → weryfikacja

Nie każdą aktualizację trzeba wdrażać natychmiast. Sposób działania powinien uwzględniać ryzyko, znaczenie systemu i wpływ zmiany na działalność.

4. Backup i odtwarzanie danych

„Mamy backup” nie oznacza jeszcze, że firma jest przygotowana na awarię lub incydent. Trzeba wiedzieć, co jest objęte backupem, jak często wykonywane są kopie, gdzie i jak długo są przechowywane oraz czy można je skutecznie odtworzyć. Warto również określić czas przywrócenia kluczowych systemów i regularnie testować odtwarzanie.

5. Monitoring i reagowanie na incydenty

Firma powinna nie tylko zapobiegać problemom, ale również wykrywać zdarzenia i wiedzieć, jak na nie reagować. Może to obejmować monitoring, ochronę endpointów, analizę logów, alerty bezpieczeństwa czy wykrywanie nietypowej aktywności.

Trzeba również określić, kto reaguje, jakie działania podjąć, kogo powiadomić i kiedy zgłosić incydent.

6. Bezpieczeństwo sieci

Warto przeanalizować m.in. zapory sieciowe, segmentację, dostęp zdalny, Wi-Fi, urządzenia sieciowe i dostęp administracyjny. Zakres zabezpieczeń powinien wynikać z ryzyka i charakteru infrastruktury.

7. Bezpieczne środowiska chmurowe

Korzystanie z chmury nie oznacza automatycznie, że wszystkie kwestie bezpieczeństwa przejmuje dostawca. Trzeba ustalić m.in. podział odpowiedzialności, zarządzanie dostępem, ochronę danych, backup, monitoring i obsługę incydentów, uwzględniając również warunki umowy.

8. Bezpieczeństwo łańcucha dostaw

Firma może być zależna od zewnętrznych dostawców IT, chmury, oprogramowania czy usług. Warto określić krytycznych dostawców, kluczowe zależności i związane z nimi ryzyka, a także wymagania bezpieczeństwa w umowach i zasady informowania o incydentach.

9. Ciągłość działania – co się stanie, jeśli IT przestanie działać?

Firma powinna być przygotowana nie tylko na atak, ale również na awarię, utratę dostępu do systemu, problem z dostawcą czy przerwę w zasilaniu. Trzeba określić, które systemy są krytyczne, jak długo firma może działać bez nich, co należy odtworzyć w pierwszej kolejności i kto podejmuje decyzje. Przyjęte scenariusze należy regularnie testować.

Backup, infrastruktura, procedury i organizacja pracy muszą razem zapewniać możliwość odtworzenia kluczowych procesów.

Cyberbezpieczeństwo – poznaj naszą ofertę

Organizacja z dobrze wdrożonym SZBI ma często uporządkowane m.in. zarządzanie ryzykiem, kontrolę dostępu, bezpieczeństwo dostawców, incydenty i ciągłość działania. ISO 27001 nie zastępuje jednak wymagań KSC. Trzeba sprawdzić, czy zakres SZBI obejmuje wszystkie istotne obszary oraz zidentyfikować ewentualne luki.

ISO 27001 ≠ automatyczna zgodność z NIS2, ale może znacząco ułatwić przygotowanie do KSC.

Jeżeli audyt lub analiza wykazały konkretne braki, kolejnym krokiem jest przełożenie ich na konkretne zadania dla IT. Przykłady:

Poprawić bezpieczeństwo dostępu administracyjnego

→ przegląd kont i uprawnień → MFA → ograniczenie dostępu uprzywilejowanego → konfiguracja i monitoring.

Zwiększyć odporność na utratę danych

→ analiza backupu → dostosowanie architektury kopii → odpowiednia retencja → testy odtworzeniowe.

Poprawić wykrywanie incydentów

→ monitoring → logowanie → alerty → określenie sposobu reakcji.

To właśnie moment, w którym wymagania i rekomendacje przekładają się na konkretną pracę IT.

Dlatego plan działań powinien uwzględniać wymagania, najważniejsze ryzyka, krytyczne systemy i dane oraz zidentyfikowane luki.

NIS2 nie oznacza „kupmy wszystko”. Oznacza „zabezpieczmy to, co istotne dla organizacji – adekwatnie do ryzyka”.

Przeczytaj: 7 nieoczywistych sygnałów, że warto wykonać audyt bezpieczeństwa IT

1. Sprawdź, czy NIS2 dotyczy Twojej firmy. Jeśli nie masz pewności – zacznij od analizy prawnej i compliance.
2. Ustal wymagania, które dotyczą Twojej organizacji.
3. Przeanalizuj obecny stan i ryzyko. Audyt, analiza luk i ocena środowiska IT mogą pomóc określić, czego brakuje.
4. Określ rekomendacje, priorytety i plan działań.
5. Przełóż rekomendacje na działania IT – wdrożenie i przetestowanie.
6. Zapewniaj bieżące utrzymanie, monitoring i aktualizacje oraz wymagane dokumentowanie, raportowanie i zgłaszanie incydentów.

• 3 października 2026 r. – termin na złożenie wniosku o wpis do Wykazu KSC,
• 3 kwietnia 2027 r. – koniec okresu na dostosowanie się do wymagań KSC,
• 3 kwietnia 2028 r. – termin pierwszego audytu dla podmiotów kluczowych, które wcześniej nie były operatorami usług kluczowych.

Terminy i obowiązki mogą zależeć od statusu podmiotu, dlatego warto zweryfikować je indywidualnie.