NIS2 dla mid-marketu: co faktycznie musi zrobić IT

czym jest NIS2 i po co powstał

Dyrektywa NIS2 (formalnie Dyrektywa (UE) 2022/2555) weszła w życie 16 stycznia 2023 roku. Państwa członkowskie miały obowiązek transponować ją do prawa krajowego do 17 października 2024 roku. Dyrektywa zastąpiła NIS1, powszechnie krytykowaną za niespójne wdrożenie w poszczególnych państwach członkowskich.

NIS2 ma podnieść minimalny poziom cyberbezpieczeństwa w całej gospodarce UE. Trzy główne mechanizmy dyrektywy to: obowiązkowe środki bezpieczeństwa dla zdefiniowanej grupy podmiotów, obowiązki raportowania incydentów, które zaczynają obowiązywać natychmiast po wystąpieniu istotnego incydentu, oraz odpowiedzialność zarządu, wiążąca osobistą odpowiedzialność z nadzorem nad cyberbezpieczeństwem. Zakres jest znacznie szerszy niż w NIS1. Komisja Europejska szacowała, że liczba podmiotów objętych obowiązkami NIS2 wzrośnie w stosunku do poprzedniej dyrektywy około dziesięciokrotnie.

kogo obejmuje: podmioty kluczowe i ważne, sektory, progi wielkości

NIS2 obejmuje organizacje w 18 wyznaczonych sektorach, które przekraczają próg wielkości 50 pracowników lub 10 milionów EUR rocznego obrotu. Niektóre kategorie, w tym dostawcy usług chmurowych, publiczne sieci łączności elektronicznej, dostawcy usług zaufania oraz rejestry domen najwyższego poziomu, są objęte zakresem niezależnie od wielkości.

Podmioty kluczowe działają w 11 sektorach o wysokiej krytyczności wymienionych w Załączniku I: energetyka, transport, bankowość, infrastruktura rynków finansowych, ochrona zdrowia, woda pitna, ścieki, infrastruktura cyfrowa, zarządzanie usługami ICT, administracja publiczna i przestrzeń kosmiczna.

Podmioty ważne działają w 7 sektorach wymienionych w Załączniku II: usługi pocztowe i kurierskie, gospodarka odpadami, chemikalia, produkcja i dystrybucja żywności, produkcja przemysłowa, dostawcy cyfrowi oraz organizacje badawcze.

Podmioty kluczowe podlegają proaktywnemu, ciągłemu nadzorowi. Podmioty ważne podlegają nadzorowi reaktywnemu, co oznacza, że regulatorzy prowadzą postępowanie, gdy pojawią się dowody nieprzestrzegania przepisów. Obowiązki wynikające z Artykułu 21 są identyczne dla obu kategorii. Duże przedsiębiorstwa (250 lub więcej pracowników albo 50 milionów EUR lub więcej obrotu) w sektorach z Załącznika I są automatycznie klasyfikowane jako kluczowe. Średnie przedsiębiorstwa (od 50 do 249 pracowników) w tych samych sektorach są zwykle uznawane za ważne, przy czym państwa członkowskie zachowują opcję zaklasyfikowania części z nich jako kluczowe.

jak ustalić, czy twoja organizacja jest objęta zakresem

Krok 1: sprawdzenie sektora. Czy główna działalność twojej organizacji mieści się w jednym z 18 sektorów objętych Załącznikiem I lub II? Jeśli główna działalność wyraźnie wykracza poza wszystkie 18 sektorów, prawdopodobnie nie jesteś objęty zakresem bezpośrednio, choć przepisy o łańcuchu dostaw mogą tworzyć pośrednie obowiązki, jeśli obsługujesz klientów objętych zakresem.

Krok 2: sprawdzenie wielkości. Czy organizacja przekracza 50 pracowników lub 10 milionów EUR rocznego obrotu? Jeśli nie, ogólny próg nie ma zastosowania, chyba że mieścisz się w kategorii zwolnionej z progu wielkości.

Krok 3: rejestracja i kto ponosi obowiązek. Niektóre państwa członkowskie wyznaczają podmioty centralnie. Inne nakładają obowiązek samodzielnej identyfikacji i rejestracji na samą organizację. Polska należy do drugiej grupy: na mocy znowelizowanej ustawy o KSC musisz sam ocenić swój status i zarejestrować się na liście KSC do 3 października 2026 roku. Nie ma wezwania ministerialnego ani pisma potwierdzającego objęcie zakresem. Traktowanie braku takiego powiadomienia jako potwierdzenia, że nie jesteś objęty zakresem, jest błędem, a w Polsce niesie ze sobą konkretną sankcję osobistą.

Jeśli po tych trzech krokach odpowiedź jest niepewna, kolejnym właściwym krokiem jest ocena prawna względem właściwej implementacji krajowej. Rola działu IT to przygotowanie się do obowiązków operacyjnych niezależnie od tego, ponieważ wymagane środki bezpieczeństwa to dobra praktyka bez względu na formalne zakwalifikowanie.

artykuł 21: 10 środków bezpieczeństwa w prostym języku

Artykuł 21(2) wymienia minimalne obszary, którymi muszą zająć się wszystkie podmioty kluczowe i ważne. Środki muszą być odpowiednie i proporcjonalne do wielkości podmiotu, jego ekspozycji na ryzyko oraz potencjalnego wpływu incydentu. Dyrektywa określa obszar, a ocenę proporcjonalności pozostawia podmiotowi.

1. Analiza ryzyka i polityki bezpieczeństwa systemów informacyjnych (a). Udokumentowany, utrzymywany proces oceny ryzyka. Doraźna świadomość ryzyka tego nie spełnia; spełnia to pisemna, okresowo weryfikowana analiza ryzyka.

2. Obsługa incydentów (b). Polityki i procedury wykrywania, analizy, powstrzymywania i przywracania sprawności po incydentach bezpieczeństwa, w tym role, ścieżki eskalacji i dokumentacja. W połączeniu z Artykułem 23 wymaga to zarówno wewnętrznej zdolności reagowania na incydenty, jak i zgodnego z wymogami procesu raportowania.

3. Ciągłość działania i zarządzanie kryzysowe (c). Zarządzanie kopiami zapasowymi, procedury odzyskiwania po awarii i zarządzania kryzysowego, z określonymi celami RTO i RPO dla systemów krytycznych. Przetestowane i udokumentowane, nie teoretyczny plan.

4. Bezpieczeństwo łańcucha dostaw (d). Ocena stanu cyberbezpieczeństwa bezpośrednich dostawców i usługodawców: oceny bezpieczeństwa dostawców, umowne wymogi cyberbezpieczeństwa oraz proces przeglądu ryzyka dostawców. Obejmuje to dostawców oprogramowania, platformy chmurowe i dostawców usług zarządzanych.

5. Bezpieczeństwo w nabywaniu, rozwoju i utrzymaniu systemów (e). Obsługa i ujawnianie podatności, wymogi bezpieczeństwa w zamówieniach oraz bezpieczne praktyki wytwarzania oprogramowania. Dla większości organizacji z segmentu mid-market dotyczy to przede wszystkim bezpieczeństwa kupowanych systemów oraz sposobu zarządzania łataniem.

6. Ocena skuteczności środków (f). Podmiot musi wykazać, że jego środki bezpieczeństwa działają zgodnie z założeniem, poprzez audyt wewnętrzny, testy penetracyjne i monitoring w zdefiniowanym cyklu, z wdrażanymi wnioskami.

7. Cyberhigiena i szkolenia (g). Szkolenia z zakresu świadomości bezpieczeństwa dla całego personelu oraz udokumentowane podstawowe praktyki higieny. Wymagane jest jedno i drugie. Ciągły, udokumentowany proces budowania świadomości ma większe szanse to spełnić niż rzadko powtarzany program odhaczania punktów.

8. Kryptografia i szyfrowanie (h). Szyfrowanie danych w spoczynku i w tranzycie tam, gdzie uzasadnia to ocena ryzyka, wraz z udokumentowanymi politykami kryptograficznymi obejmującymi zarządzanie kluczami.

9. Bezpieczeństwo kadrowe, polityki kontroli dostępu i zarządzanie aktywami (i). Obszar najbardziej bezpośrednio związany z zarządzaniem tożsamością i dostępem. Wymaga kontroli dostępu opartej na zasadzie need-to-know i least privilege, udokumentowanych polityk określających, kto ma dostęp do czego i dlaczego, inwentarza aktywów oraz środków bezpieczeństwa personalnego, w tym procesów joiner-mover-leaver. Bezpośrednio wpisują się tu przeglądy dostępów, kontrole dostępu uprzywilejowanego, procedury offboardingu i zarządzanie kontami serwisowymi.

10. Uwierzytelnianie wieloskładnikowe lub ciągłe oraz zabezpieczona komunikacja (j). MFA jest wprost wymagane „tam, gdzie stosowne”, co dla środowiska IT oznacza konta administracyjne, dostęp zdalny oraz dostęp do systemów przetwarzających dane wrażliwe lub krytyczne.

artykuł 23: terminy raportowania incydentów

Gdy dojdzie do istotnego incydentu, Artykuł 23 nakłada trzyetapowy obowiązek raportowania do właściwego krajowego CSIRT lub organu właściwego. Istotny incydent to taki, który powoduje lub może potencjalnie spowodować poważne zakłócenie działania, straty finansowe lub znaczną szkodę dla innych osób.

Etap 1: wczesne ostrzeżenie, w ciągu 24 godzin. Krótkie wstępne powiadomienie wskazujące, że doszło do incydentu, czy jest podejrzenie działania złośliwego oraz czy może mieć skutki transgraniczne. Zegar liczy się od momentu, w którym podmiot dowiedział się o incydencie, nie od jego rozpoczęcia.

Etap 2: powiadomienie o incydencie, w ciągu 72 godzin. Zaktualizowana ocena obejmująca dotkliwość i wpływ, wstępne rozpoznanie przyczyny źródłowej, jeśli jest dostępne, oraz wskaźniki naruszenia (IoC), jeśli są znane.

Etap 3: raport końcowy, w ciągu miesiąca od powiadomienia z etapu 2. Szczegółowe zestawienie: co się wydarzyło, jak sobie z tym poradzono, jaki był rzeczywisty wpływ i jakie kroki zapobiegają powtórce.

Obowiązek raportowania wymaga, aby zespoły IT i bezpieczeństwa potrafiły szybko wykrywać, oceniać i dokumentować incydenty. Organizacja, która nie ma infrastruktury logowania pozwalającej odtworzyć przebieg zdarzeń, będzie miała trudność zarówno z dotrzymaniem terminu, jak i ze spełnieniem wymogów dowodowych. Dla dostawców usług zaufania obowiązuje bardziej rygorystyczny 24-godzinny termin powiadomienia.

artykuł 20: odpowiedzialność zarządu

Artykuł 20 najbardziej zmienia rozmowę na poziomie zarządu. Organy zarządzające muszą zatwierdzać środki zarządzania ryzykiem cyberbezpieczeństwa podejmowane przez ich organizacje na mocy Artykułu 21 i nadzorować ich wdrożenie. Członkowie zarządu ponoszą osobistą odpowiedzialność za naruszenia, jeśli nie sprawowali odpowiedniego nadzoru. Dyrektywa wymaga też od nich odbycia szkolenia wystarczającego do rozpoznawania ryzyk cyberbezpieczeństwa.

Struktura kar to odzwierciedla: kary dla podmiotów kluczowych mogą sięgać 10 milionów EUR lub 2% globalnego rocznego obrotu, w zależności od tego, która wartość jest wyższa. Dla podmiotów ważnych pułap wynosi 7 milionów EUR lub 1,4%. Poszczególni dyrektorzy mogą też otrzymać publiczną naganę albo zakaz pełnienia funkcji zarządczych. Niemiecka implementacja (obowiązująca od 6 grudnia 2025 roku) czyni organy zarządzające osobiście odpowiedzialnymi za szkody wynikające z naruszeń obowiązków w zakresie cyberbezpieczeństwa, a firma nie może zwolnić członków zarządu z tej odpowiedzialności.

stan implementacji w UE i w Polsce

NIS2 wymagała implementacji do 17 października 2024 roku. Większość państw członkowskich nie dotrzymała tego terminu. Według stanu na czerwiec 2026 roku 23 z 27 państw wdrożyło NIS2; Francja, Irlandia, Holandia i Hiszpania pozostają na etapie projektu (ECSO NIS2 Transposition Tracker, czerwiec 2026). Komisja Europejska wszczęła postępowania w sprawie uchybienia zobowiązaniom w listopadzie 2024 roku i w maju 2025 roku wydała uzasadnione opinie wobec 19 państw członkowskich. Działania egzekucyjne trwają już w Niemczech, Holandii i Francji.

Polska (stan na czerwiec 2026 roku): Polska implementowała NIS2 poprzez nowelizację ustawy o Krajowym Systemie Cyberbezpieczeństwa (KSC), w wersji powszechnie nazywanej UKSC 2.0. Prezydent podpisał ją 19 lutego 2026 roku, a weszła w życie 3 kwietnia 2026 roku. Wdrożenie przebiega według harmonogramu etapowego:

• 3 kwietnia 2026. UKSC 2.0 wchodzi w życie. Od tej daty obowiązują proaktywny nadzór, kontrole doraźne oraz obowiązek raportowania incydentów.
• 3 października 2026. Termin samoidentyfikacji w rejestrze KSC. Firmy same oceniają swój status i się rejestrują.
• 3 kwietnia 2027. Pełne wdrożenie obowiązków NIS2, wraz z zamknięciem okna przejściowego dla merytorycznych środków.
• 3 kwietnia 2028. Pierwsze obowiązkowe audyty podmiotów kluczowych, moment, w którym zaczyna się egzekwowanie oparte na audytach.

Praktyczne ostrzeżenie dla polskich firm: nie daj się uśpić dacie audytu w 2028 roku. Proaktywny nadzór, kontrole doraźne i raportowanie incydentów obowiązują już od 3 kwietnia 2026 roku. Obok kar na poziomie firmy prezes zarządu może ponieść indywidualną karę do 300% swojego wynagrodzenia, na przykład gdy firma objęta zakresem nie dopełniła obowiązku rejestracji.

co IT musi faktycznie zrobić: podsumowanie gotowości

To zestawienie mapuje obszary Artykułu 21 na konkretne działania IT. To punkt wyjścia, nie ocena prawna.

Zakres i governance. Potwierdź, czy organizacja jest objęta zakresem, sprawdź, jak twoje państwo członkowskie wyznacza podmioty, przedstaw zakres i obowiązki NIS2 zarządowi i najwyższemu kierownictwu (Artykuł 20 nakazuje zatwierdzenie przez zarząd) i udokumentuj wynik.

Zarządzanie ryzykiem. Ustanów lub zaktualizuj formalny proces oceny ryzyka obejmujący sieci i systemy informacyjne, udokumentuj go i ustal cykl przeglądu co najmniej raz w roku.

Reagowanie na incydenty. Zdefiniuj, co stanowi istotny incydent, udokumentuj procedury wykrywania i eskalacji, wskaż, kto odpowiada za każdy etap procesu raportowania z Artykułu 23, przetestuj proces ćwiczeniem typu tabletop i wdróż logowanie zgodne z 24-godzinnym terminem raportowania.

Ciągłość działania. Udokumentuj procedury tworzenia kopii zapasowych i cele RTO/RPO, przetestuj procedury odtwarzania i utrzymuj plan ciągłości działania oraz odzyskiwania po awarii.

Łańcuch dostaw. Zinwentaryzuj krytycznych dostawców zewnętrznych, oceń ich stan bezpieczeństwa, uwzględnij wymogi cyberbezpieczeństwa w nowych umowach i sprawdź praktyki dostawców w zakresie ujawniania podatności.

Kontrola dostępu i zarządzanie aktywami. Utrzymuj aktualny inwentarz aktywów, udokumentuj polityki dostępu oparte na least privilege, prowadź proces joiner-mover-leaver, który zamyka dostęp również w aplikacjach SaaS, przeprowadzaj okresowe przeglądy dostępów, zarządzaj dostępem uprzywilejowanym osobno oraz inwentaryzuj i przeglądaj konta serwisowe.

Uwierzytelnianie wieloskładnikowe. Wymuś MFA na wszystkich kontach administracyjnych, dostępie zdalnym i systemach przetwarzających dane wrażliwe oraz sprawdzaj luki tam, gdzie nowe systemy albo konta serwisowe nie mają równoważnej ochrony.

Cyberhigiena, kryptografia i skuteczność. Prowadź udokumentowane szkolenia w zdefiniowanym cyklu, przeglądaj szyfrowanie danych w spoczynku i w tranzycie oraz planuj okresowe oceny, których wyniki są śledzone i prezentowane zarządowi.

jak tożsamość, dostęp i higiena SaaS wpisują się w artykuł 21

Kilka środków z Artykułu 21 koncentruje się w obszarze tożsamości i dostępu. To nie przypadek: przejęte dane uwierzytelniające i nadmierny dostęp należą do najczęstszych wektorów wejścia w incydentach, które uruchamiają obowiązki raportowania NIS2.

Artykuł 21(2)(i) wprost wymaga polityk kontroli dostępu i zarządzania aktywami: aktualnego inwentarza kont we wszystkich systemach, nie tylko w głównym katalogu, udokumentowanych polityk least privilege, działającego procesu JML, który zamyka dostęp również w aplikacjach SaaS (offboarding, który zamyka konto w Entra albo Okta, ale zostawia otwarty dostęp do aplikacji SaaS, nie spełnia tego wymogu), oraz cykli przeglądów dostępów z udokumentowanymi decyzjami.

Artykuł 21(2)(j) wprost wymaga MFA. Dla większości środowisk mid-market domknięcie luk w MFA to najszybsza droga od zera do wiarygodnej postawy kontrolnej. Higiena SaaS łączy się zarówno z Artykułem 21(2)(i), jak i (d): aplikacje shadow SaaS niosą dostęp, którego IT nie może przejrzeć, a granty OAuth mogą dać zewnętrznym aplikacjom dostęp do danych wrażliwych, nie pojawiając się w standardowym przeglądzie dostępów.

częste nieporozumienia

„Jesteśmy za mali, żeby nas to obejmowało.” Próg to 50 pracowników lub 10 milionów EUR obrotu, pod warunkiem że organizacja działa w objętym sektorze. Firma z 60 pracownikami w łańcuchu dostaw energetyki, usługach finansowych czy ochronie zdrowia najprawdopodobniej jest objęta zakresem. Sektor liczy się tak samo jak wielkość.

„Naszego sektora nie ma na liście, więc nas to nie dotyczy.” Obowiązki dotyczące łańcucha dostaw z Artykułu 21(2)(d) oznaczają, że podmioty objęte zakresem muszą narzucać wymogi bezpieczeństwa swoim dostawcom. Firma nieobjęta zakresem bezpośrednio, która obsługuje podmioty objęte zakresem, i tak napotka pośrednie obowiązki poprzez umowy.

„Nie dostaliśmy powiadomienia o zakwalifikowaniu, więc nie jesteśmy objęci zakresem.” Krajowe procesy wyznaczania podmiotów w wielu państwach członkowskich wciąż trwały według stanu na czerwiec 2026 roku. Brak formalnego powiadomienia nie potwierdza, że firma nie jest objęta zakresem.

„NIS2 wymaga od nas certyfikacji zgodności.” Nie istnieje schemat certyfikacji NIS2. Dyrektywa wymaga środków bezpieczeństwa, które można wykazać, oraz dowodów, że działają. ISO 27001 daje istotne pokrycie, ale nie zastępuje zgodności z prawem krajowym.

„Raportowanie incydentów dotyczy tylko naruszeń danych.” Artykuł 23 dotyczy istotnych incydentów wpływających na dostępność, integralność lub poufność. Ransomware, który zakłóca działanie bez ujawnienia danych osobowych, mieści się w zakresie. Zakres raportowania jest szerszy niż w RODO.

„Zespół IT może to załatwić bez angażowania zarządu.” Artykuł 20 jest jednoznaczny: organy zarządzające muszą zatwierdzić środki, nadzorować wdrożenie i odbyć szkolenie. Odpowiedzialność osobista spoczywa na zarządzie.