NIS2 dla firm IT — kogo obejmie i jakie dokumenty przygotować?

NIS2 jest jedną z najważniejszych regulacji dotyczących cyberbezpieczeństwa przedsiębiorstw działających w Unii Europejskiej. Jej celem jest podniesienie poziomu odporności systemów informacyjnych w sektorach, których zakłócenie mogłoby wywołać poważne skutki gospodarcze, społeczne albo publiczne. Regulacja obejmuje nie tylko energetykę, transport, bankowość, ochronę zdrowia i administrację, lecz również szeroko rozumianą infrastrukturę cyfrową oraz zarządzanie usługami ICT.

Dla branży IT najważniejsze pytanie nie brzmi jednak, czy firma tworzy oprogramowanie albo zatrudnia programistów. Sam fakt prowadzenia software house’u nie powoduje automatycznie objęcia przepisami wdrażającymi NIS2. Znaczenie ma rodzaj faktycznie świadczonych usług, wielkość przedsiębiorstwa, sektor działalności oraz to, czy firma spełnia definicję jednego z podmiotów wymienionych w ustawie o krajowym systemie cyberbezpieczeństwa.

W Polsce dyrektywa NIS2 została wdrożona ustawą z 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa oraz niektórych innych ustaw. Ustawa została ogłoszona 2 marca 2026 r. i weszła w życie po upływie miesiąca, a więc 2 kwietnia 2026 r. Polski ustawodawca zastąpił dotychczasową konstrukcję operatorów usług kluczowych oraz dostawców usług cyfrowych systemem podmiotów kluczowych i podmiotów ważnych. (ELI)

Nie oznacza to, że od 2 kwietnia 2026 r. każda firma objęta ustawą musiała posiadać kompletny system zarządzania bezpieczeństwem informacji. Podmioty, które spełniały przesłanki uznania za podmiot kluczowy albo ważny w dniu wejścia nowelizacji w życie, otrzymały dwanaście miesięcy na realizację obowiązków określonych w rozdziale dotyczącym bezpieczeństwa systemów informacyjnych. W praktyce podstawowy termin dostosowania dla tej grupy przypada 2 kwietnia 2027 r. Pierwszy obowiązkowy audyt podmiotu kluczowego powinien zostać przeprowadzony w terminie dwudziestu czterech miesięcy od wejścia ustawy w życie.

Okres przejściowy nie powinien jednak prowadzić do odkładania wdrożenia. Przygotowanie analizy zakresu, systemu zarządzania bezpieczeństwem informacji, procedur incydentowych, zarządzania dostawcami, planów ciągłości działania i dokumentacji operacyjnej może zająć wiele miesięcy. Firma, która rozpocznie prace dopiero na początku 2027 r., może nie zdążyć przeprowadzić analizy ryzyka, wdrożyć zabezpieczeń, przeszkolić personelu i przetestować procedur przed terminem ustawowym.

Czym jest NIS2?

NIS2 to dyrektywa Parlamentu Europejskiego i Rady 2022/2555 dotycząca środków na rzecz wysokiego wspólnego poziomu cyberbezpieczeństwa na terytorium Unii Europejskiej. Zastąpiła wcześniejszą dyrektywę NIS i znacznie rozszerzyła katalog sektorów oraz podmiotów objętych obowiązkami.

Dyrektywa wymaga od państw członkowskich stworzenia systemu obejmującego zarządzanie ryzykiem w cyberbezpieczeństwie, zgłaszanie poważnych incydentów, nadzór, audyty, współpracę z organami i odpowiedzialność kierownictwa. Obejmuje zasadniczo średnie i duże podmioty prowadzące działalność w sektorach wskazanych w załącznikach, ale przewiduje także przypadki objęcia podmiotów niezależnie od ich wielkości.

Dyrektywa nie działa wobec przedsiębiorcy wyłącznie dlatego, że jest unijnym aktem prawnym. Jako dyrektywa wymaga wdrożenia do prawa krajowego. W Polsce podstawowe obowiązki przedsiębiorstw wynikają więc obecnie przede wszystkim ze znowelizowanej ustawy o krajowym systemie cyberbezpieczeństwa.

W komunikacji biznesowej nadal powszechnie używa się określenia „zgodność z NIS2”, choć w praktyce polski przedsiębiorca powinien sprawdzać obowiązki wynikające z krajowej ustawy, rozporządzeń wykonawczych oraz przepisów unijnych stosowanych bezpośrednio do niektórych kategorii podmiotów.

Czy każda firma IT podlega NIS2?

Nie. Podstawowym błędem jest założenie, że każdy software house, producent aplikacji, freelancer albo agencja programistyczna staje się podmiotem kluczowym lub ważnym tylko dlatego, że działa w branży technologicznej.

Firma tworząca strony internetowe, aplikacje mobilne albo dedykowane oprogramowanie może pozostawać poza bezpośrednim zakresem ustawy, jeżeli nie świadczy usług mieszczących się w jednej z ustawowych kategorii i nie została indywidualnie zidentyfikowana przez organ.

Inaczej może wyglądać sytuacja firmy, która nie tylko tworzy kod, lecz również utrzymuje systemy klientów, administruje ich środowiskami, zarządza serwerami, kontami, kopiami zapasowymi, aktualizacjami, bezpieczeństwem albo reagowaniem na incydenty. Taka działalność może spełniać definicję dostawcy usług zarządzanych albo dostawcy usług zarządzanych w zakresie cyberbezpieczeństwa.

Ustawa definiuje dostawcę usług zarządzanych jako podmiot świadczący usługi związane z instalacją, eksploatacją lub konserwacją produktów ICT, usług ICT, procesów ICT albo systemów informacyjnych przez wsparcie lub aktywną administrację prowadzoną u klienta albo zdalnie. Dostawcą usług zarządzanych w zakresie cyberbezpieczeństwa jest natomiast podmiot realizujący lub wspierający zarządzanie ryzykiem cyberbezpieczeństwa, w tym obsługę incydentów, testy bezpieczeństwa, audyty systemów i doradztwo.

Oznacza to, że firma określająca się marketingowo jako software house może w świetle ustawy być dostawcą usług zarządzanych, jeżeli jej rzeczywiste usługi obejmują aktywną administrację systemami klientów. Z kolei spółka nazywająca się dostawcą IT może pozostawać poza tą kategorią, jeżeli jedynie jednorazowo tworzy i przekazuje oprogramowanie, nie zarządzając później środowiskiem klienta.

Ocena powinna opierać się na umowach, ofertach, dokumentacji usług, modelu odpowiedzialności i faktycznych czynnościach zespołu, a nie wyłącznie na kodzie PKD albo opisie na stronie internetowej.

Dostawca usług zarządzanych

Dostawcy usług zarządzanych zostali wskazani w sektorze zarządzania usługami ICT. Ustawa obejmuje przede wszystkim podmioty, które administrują systemami informacyjnymi innych organizacji i posiadają możliwość oddziaływania na ich konfigurację, funkcjonowanie lub bezpieczeństwo.

Przykładem może być firma prowadząca stałą administrację serwerami klienta, zarządzająca środowiskiem Microsoft 365, usługami chmurowymi, urządzeniami końcowymi, siecią, kopiami zapasowymi, aktualizacjami, kontami użytkowników albo monitoringiem infrastruktury.

Nie każda usługa wsparcia technicznego musi jednak automatycznie prowadzić do uznania firmy za dostawcę usług zarządzanych. Znaczenie ma aktywna administracja, a nie samo udzielanie konsultacji albo sporadyczna pomoc użytkownikowi.

Firma powinna przeanalizować, czy jej personel może dokonywać zmian w systemach klienta, posiada konta administracyjne, wykonuje aktualizacje, zarządza konfiguracją, odpowiada za ciągłość działania albo świadczy stały helpdesk połączony z obsługą infrastruktury.

Wątpliwości może budzić utrzymanie aplikacji stworzonej przez software house. Jeżeli wykonawca jedynie usuwa błędy we własnym kodzie i przygotowuje aktualizacje, kwalifikacja nie zawsze będzie oczywista. Jeżeli jednak posiada dostęp do środowiska produkcyjnego, administruje usługą, wdraża poprawki, monitoruje dostępność i zarządza infrastrukturą klienta, ryzyko objęcia ustawą rośnie.

Dostawca usług zarządzanych w zakresie cyberbezpieczeństwa

Szczególnie szeroko objęte są firmy świadczące zarządzane usługi bezpieczeństwa. Mogą to być operatorzy SOC, dostawcy monitoringu bezpieczeństwa, firmy reagujące na incydenty, podmioty prowadzące testy bezpieczeństwa, audyty systemów oraz doradztwo w zakresie zarządzania ryzykiem.

Polska ustawa przyjęła w odniesieniu do tej grupy rozwiązanie bardziej rygorystyczne niż ogólna zasada dotycząca średnich i dużych przedsiębiorstw. Dostawca usług zarządzanych w zakresie cyberbezpieczeństwa może zostać podmiotem kluczowym już wtedy, gdy co najmniej spełnia kryteria małego przedsiębiorcy.

W praktyce oznacza to, że stosunkowo niewielka firma świadcząca zarządzane usługi bezpieczeństwa może zostać zakwalifikowana jako podmiot kluczowy, mimo że typowy dostawca innych usług zarządzanych o podobnej wielkości nie zostałby objęty na tych samych zasadach.

Należy odróżnić dostawcę zarządzanej usługi cyberbezpieczeństwa od firmy, która jednorazowo wykonała test penetracyjny albo przygotowała dokumentację. Ustawowa definicja jest jednak szeroka i obejmuje także testy, audyty oraz doradztwo. Dlatego firmy świadczące tego rodzaju usługi powinny przeprowadzić szczególnie dokładną analizę, zamiast automatycznie zakładać, że NIS2 dotyczy wyłącznie centrów operacji bezpieczeństwa.

Dostawcy chmury i centrów danych

Ustawą mogą zostać objęci dostawcy chmury obliczeniowej, usług centrów przetwarzania danych, sieci dostarczania treści, usług DNS, rejestracji domen, usług zaufania, komunikacji elektronicznej, platform handlowych, wyszukiwarek i platform społecznościowych.

Przedsiębiorca oferujący aplikację SaaS nie zawsze jest dostawcą chmury obliczeniowej w rozumieniu ustawy. Sam fakt, że oprogramowanie działa w chmurze AWS, Microsoft Azure lub Google Cloud, nie powoduje, że operator aplikacji staje się dostawcą infrastruktury chmurowej.

Należy zbadać, czy firma rzeczywiście oferuje klientom skalowalne, elastyczne i współdzielone zasoby obliczeniowe, czy jedynie korzysta z usług innego dostawcy w celu hostowania własnej aplikacji.

Podobnie nie każdy hosting jest automatycznie centrum przetwarzania danych. Ustawowa definicja odnosi się do struktur przeznaczonych do scentralizowanego hostingu, zapewniania wzajemnych połączeń i eksploatacji produktów, usług lub procesów ICT wraz z odpowiednią infrastrukturą techniczną.

Wielkość przedsiębiorstwa

W większości przypadków zastosowanie ustawy zależy nie tylko od sektora, lecz także od wielkości podmiotu.

Co do zasady podmiot wskazany w pierwszym załączniku staje się podmiotem kluczowym, jeżeli przekracza kryteria średniego przedsiębiorstwa. Podmiot wskazany w tym załączniku spełniający kryteria średniego przedsiębiorcy może zostać podmiotem ważnym. Podmioty wskazane w drugim załączniku co najmniej średniej wielkości również mogą być podmiotami ważnymi.

Ocena wielkości nie powinna ograniczać się do liczby pracowników wpisanej w jednej spółce. Unijne zasady kwalifikacji przedsiębiorstw wymagają uwzględniania także danych przedsiębiorstw partnerskich i powiązanych.

Grupa kapitałowa nie powinna więc zakładać, że pojedyncza spółka jest małym przedsiębiorcą tylko dlatego, że zatrudnia kilkanaście osób. Powiązania właścicielskie i kontrolne mogą spowodować konieczność uwzględnienia danych całej grupy.

Niektóre kategorie podmiotów są objęte niezależnie od wielkości. Dotyczy to między innymi dostawców DNS, kwalifikowanych dostawców usług zaufania, rejestrów nazw domen najwyższego poziomu oraz podmiotów świadczących rejestrację nazw domen. Ustawa umożliwia także indywidualne zidentyfikowanie podmiotu jako kluczowego lub ważnego ze względu na znaczenie świadczonych przez niego usług.

Podmiot kluczowy a podmiot ważny

Podział na podmioty kluczowe i ważne wpływa przede wszystkim na model nadzoru, zakres audytów i wysokość potencjalnych kar.

Podmiot kluczowy jest zasadniczo organizacją większą albo wykonującą usługę o szczególnym znaczeniu. Podmiot ważny może prowadzić działalność w tym samym sektorze, ale spełniać niższy próg wielkości albo działać w sektorze uznanym za mniej krytyczny.

Obie grupy mają jednak realizować podstawowe obowiązki dotyczące systemu zarządzania bezpieczeństwem informacji, ryzyka, incydentów, dokumentacji, ciągłości działania, bezpieczeństwa łańcucha dostaw oraz szkolenia personelu.

Nie należy więc traktować statusu podmiotu ważnego jako zwolnienia z wdrożenia. Różnice dotyczą głównie intensywności kontroli oraz niektórych instrumentów nadzorczych, a nie rezygnacji z podstawowych środków bezpieczeństwa.

Czy wpis do wykazu tworzy obowiązki?

Nowelizacja przewiduje wykaz podmiotów kluczowych i ważnych. Podmioty objęte ustawą powinny złożyć wniosek o wpis zgodnie z harmonogramem ogłoszonym przez ministra właściwego do spraw informatyzacji. Organ może również dokonać wpisu, jeżeli podmiot nie złoży wniosku mimo spełnienia przesłanek.

Firma nie powinna jednak zakładać, że dopóki nie otrzyma zawiadomienia albo nie zobaczy swojej nazwy w wykazie, nie ma żadnych obowiązków.

Podstawą objęcia regulacją jest spełnienie przesłanek ustawowych. Wpis służy ewidencji i organizacji nadzoru, ale nie powinien być traktowany jako jedyny moment powstania statusu.

Dlatego przedsiębiorca powinien samodzielnie przeprowadzić analizę kwalifikacyjną. Powinna ona obejmować sektor działalności, rodzaj usług, wielkość przedsiębiorstwa, powiązania kapitałowe, miejsce prowadzenia działalności oraz ewentualne wyjątki.

Wynik analizy warto utrwalić w formie pisemnej. Jeżeli firma uzna, że nie podlega ustawie, dokument powinien wyjaśniać podstawy tej oceny. Jest to szczególnie ważne, gdy działalność znajduje się na granicy usług programistycznych i aktywnego zarządzania systemami klientów.

System zarządzania bezpieczeństwem informacji

Podstawowym obowiązkiem podmiotu kluczowego lub ważnego jest wdrożenie systemu zarządzania bezpieczeństwem informacji obejmującego systemy wykorzystywane do świadczenia usługi.

Nie chodzi jedynie o zakup programu antywirusowego, wykonanie testu penetracyjnego albo przygotowanie jednej polityki bezpieczeństwa.

System powinien opierać się na zarządzaniu ryzykiem. Firma musi ustalić, jakie systemy i zasoby są istotne, jakie zagrożenia mogą na nie oddziaływać, jakie są podatności, jakie skutki może wywołać incydent i jakie zabezpieczenia należy zastosować.

Zabezpieczenia powinny obejmować aspekty organizacyjne, techniczne, operacyjne i fizyczne. Muszą być utrzymywane, weryfikowane i aktualizowane, a nie wyłącznie opisane w dokumentach.

Certyfikacja ISO 27001 może ułatwić wdrożenie, ale sama w sobie nie jest automatycznym potwierdzeniem spełnienia wszystkich wymagań ustawy. Zakres certyfikacji może być zbyt wąski, dokumentacja nieaktualna, a część obowiązków NIS2 może wykraczać poza istniejący system.

Jaką dokumentację należy przygotować?

Polska ustawa wprost wymaga opracowania, stosowania i aktualizowania dokumentacji bezpieczeństwa systemu informacyjnego wykorzystywanego przy świadczeniu usługi.

Dokumentacja dzieli się na normatywną i operacyjną. Dokumentacja normatywna obejmuje zasady, polityki, procedury, plany i opisy systemów. Dokumentacja operacyjna obejmuje zapisy potwierdzające, że organizacja rzeczywiście wykonuje wymagane czynności, w tym automatycznie generowane zapisy z dzienników systemowych.

To rozróżnienie ma podstawowe znaczenie. Firma może posiadać rozbudowaną politykę bezpieczeństwa, ale jeżeli nie wykonuje przeglądów dostępów, nie testuje kopii zapasowych, nie rejestruje szkoleń i nie dokumentuje obsługi incydentów, nie będzie w stanie wykazać rzeczywistego wdrożenia.

Dokumentacja powinna odpowiadać skali i charakterowi działalności. Niewielki dostawca usług zarządzanych nie musi kopiować kilkusetstronicowego systemu dokumentacyjnego międzynarodowego banku. Musi jednak posiadać procedury wystarczające do zarządzania swoim ryzykiem i wykazania wykonania obowiązków.

Analiza kwalifikacyjna NIS2

Pierwszym dokumentem powinna być analiza zakresu zastosowania ustawy.

Powinna wskazywać, jakie usługi świadczy firma, do której kategorii ustawowej mogą należeć, jaki jest jej status wielkościowy oraz czy należy uwzględnić przedsiębiorstwa powiązane.

W przypadku software house’u analiza powinna rozróżniać tworzenie oprogramowania, utrzymanie kodu, hosting, monitoring, aktywną administrację, zarządzanie kontami, helpdesk, cyberbezpieczeństwo i dostęp do środowisk klientów.

Należy również ustalić, które spółki z grupy świadczą usługę i zawierają umowy. Nie zawsze podmiot zatrudniający zespół jest tym samym podmiotem, który formalnie świadczy usługę klientowi.

Analiza powinna zakończyć się jednoznacznym wnioskiem, czy firma jest podmiotem kluczowym, ważnym, potencjalnie objętym po przekroczeniu progu albo pozostającym poza bezpośrednim zakresem.

Dokument powinien być aktualizowany po zmianie modelu usług, przejęciu innej spółki, wzroście przedsiębiorstwa albo rozpoczęciu świadczenia nowych usług.

Polityka bezpieczeństwa informacji

Polityka bezpieczeństwa informacji powinna określać najważniejsze zasady organizacji systemu bezpieczeństwa.

Powinna wskazywać cele, zakres, role, odpowiedzialność kierownictwa, sposób zarządzania ryzykiem, strukturę dokumentacji, podstawowe zasady dostępu oraz sposób raportowania nieprawidłowości.

Nie powinna być ogólnym dokumentem skopiowanym z internetu. Musi odpowiadać rzeczywistej organizacji, używanym systemom i usługom.

Jeżeli firma działa zdalnie, korzysta z chmury i nie posiada własnej serwerowni, polityka opisująca ochronę szaf serwerowych w siedzibie nie ma praktycznego znaczenia.

Dokument powinien być zatwierdzony przez kierownictwo, komunikowany personelowi i okresowo przeglądany.

Metodyka i analiza ryzyka

Firma powinna przyjąć metodę identyfikowania, analizowania i oceny ryzyka.

Metodyka powinna określać skalę prawdopodobieństwa i skutków, kryteria akceptacji ryzyka, sposób wyboru zabezpieczeń, właścicieli ryzyka oraz częstotliwość przeglądów.

Na jej podstawie należy przygotować rejestr ryzyk. Powinien on obejmować między innymi awarie systemów, ransomware, przejęcie kont uprzywilejowanych, utratę danych, błędy konfiguracji, podatności oprogramowania, niedostępność dostawców, działania personelu i ryzyka fizyczne.

W firmach IT szczególnie ważne są ryzyka związane z kontami administracyjnymi do systemów klientów. Przejęcie jednego konta dostawcy usług zarządzanych może umożliwić atak na wiele organizacji.

Analiza ryzyka powinna prowadzić do planu postępowania z ryzykiem. Nie wystarczy opisać zagrożeń. Należy wskazać działania, terminy, osoby odpowiedzialne i ryzyko pozostające po wdrożeniu zabezpieczeń.

Inwentaryzacja aktywów

Bez aktualnej inwentaryzacji firma nie jest w stanie skutecznie zarządzać ryzykiem.

Rejestr powinien obejmować sprzęt, systemy, aplikacje, usługi chmurowe, repozytoria, bazy danych, konta uprzywilejowane, integracje, domeny, certyfikaty, klucze, urządzenia sieciowe i istotnych dostawców.

Należy wskazać właściciela aktywa, jego znaczenie, lokalizację, kategorie danych, zależności oraz wymagany poziom ochrony.

W firmie IT warto odrębnie ewidencjonować dostępy do środowisk klientów. Pracownik albo podwykonawca może posiadać uprawnienia do wielu organizacji, co zwiększa skutki przejęcia jego konta.

Inwentaryzacja powinna być powiązana z procesem zatrudniania, zmiany roli i zakończenia współpracy.

Procedura zarządzania dostępem

Dokumentacja powinna regulować tworzenie, zmianę, przegląd i usuwanie uprawnień.

Należy stosować zasadę najmniejszych uprawnień i wiedzy koniecznej. Dostęp administracyjny powinien być przyznawany tylko osobom, które rzeczywiście go potrzebują.

Procedura powinna obejmować uwierzytelnianie wieloskładnikowe, konta uprzywilejowane, hasła, klucze API, dostęp zdalny, konta serwisowe oraz zasady korzystania z menedżerów haseł.

Firma powinna dokumentować okresowe przeglądy dostępów. Sama deklaracja, że uprawnienia są sprawdzane, nie wystarczy podczas audytu.

Szczególne znaczenie ma natychmiastowe odbieranie dostępów po zakończeniu współpracy oraz aktualizowanie uprawnień po zmianie projektu.

Procedura obsługi incydentów

Podmiot powinien posiadać procedurę pozwalającą wykryć, sklasyfikować, obsłużyć i udokumentować incydent.

Procedura powinna wskazywać kanały zgłaszania, osoby decyzyjne, role zespołu, sposób eskalacji, zabezpieczenie dowodów, komunikację z klientami, organami i ubezpieczycielem oraz zasady analizy przyczyn.

Powinna również uwzględniać ustawowy system zgłaszania incydentów poważnych. Ustawa przewiduje wczesne ostrzeżenie przekazywane niezwłocznie, nie później niż w ciągu dwudziestu czterech godzin od wykrycia, właściwe zgłoszenie nie później niż w ciągu siedemdziesięciu dwóch godzin oraz sprawozdanie końcowe zasadniczo w ciągu miesiąca.

Firma musi więc posiadać proces pozwalający bardzo szybko ustalić, czy zdarzenie może spełniać kryteria incydentu poważnego. Nie można czekać z rozpoczęciem analizy do zakończenia pełnego dochodzenia technicznego.

Pierwsze ostrzeżenie może opierać się na wstępnych informacjach. Procedura powinna umożliwiać ich późniejsze uzupełnianie.

Incydent może jednocześnie stanowić naruszenie ochrony danych osobowych. Należy więc skoordynować procedurę NIS2 z procedurą RODO, aby uniknąć sprzecznych zgłoszeń i utraty terminów.

Plan ciągłości działania

Firma powinna przygotować dokumentację zarządzania ciągłością działania.

Należy ustalić krytyczne usługi, systemy i procesy, maksymalny tolerowany czas przerwy, wymagany czas odtworzenia oraz dopuszczalną utratę danych.

Plan powinien obejmować scenariusze awarii infrastruktury, chmury, sieci, dostawcy, biura, systemu uwierzytelniania, repozytorium oraz niedostępności kluczowego personelu.

Kopie zapasowe muszą być nie tylko tworzone, ale również testowane. Dokumentacja operacyjna powinna potwierdzać wykonanie testów odtworzenia.

W firmie zarządzającej systemami klientów plan powinien uwzględniać priorytety obsługi wielu organizacji podczas jednoczesnego incydentu.

Plan odtwarzania po awarii

Disaster recovery powinien opisywać techniczne kroki potrzebne do przywrócenia systemów.

Dokument powinien wskazywać kolejność odtwarzania, osoby odpowiedzialne, lokalizację kopii, wymagane dane dostępowe, zależności i sposób potwierdzenia poprawności działania.

Plan musi być możliwy do wykonania również wtedy, gdy podstawowa infrastruktura, poczta albo system dokumentacji są niedostępne.

Należy zadbać o bezpieczny dostęp do instrukcji awaryjnych i danych kontaktowych poza głównym środowiskiem.

Bezpieczeństwo łańcucha dostaw

NIS2 kładzie duży nacisk na ryzyko związane z dostawcami i usługami zewnętrznymi.

Firma IT powinna stworzyć procedurę wyboru, oceny i monitorowania dostawców. Powinna ona obejmować dostawców chmury, hostingu, repozytoriów, systemów komunikacji, narzędzi bezpieczeństwa, podwykonawców, freelancerów i dostawców komponentów.

Ocena nie powinna kończyć się na sprawdzeniu ceny i dostępności usługi. Należy uwzględnić poziom bezpieczeństwa, lokalizacje, możliwość audytu, historię incydentów, ciągłość działania, zasady podwykonawstwa, zakończenie umowy i dostęp do danych.

Umowy powinny regulować termin zgłaszania incydentów, współpracę przy analizie, minimalne środki bezpieczeństwa, zwrot danych, prawo audytu i odpowiedzialność.

Firma będąca dostawcą usług zarządzanych powinna jednocześnie spodziewać się, że jej klienci objęci NIS2 będą wymagali rozbudowanych klauzul bezpieczeństwa. Nawet software house nieobjęty bezpośrednio ustawą może więc otrzymywać wymagania wynikające z obowiązków swojego klienta.

Zarządzanie podatnościami i aktualizacjami

Dokumentacja powinna obejmować proces identyfikowania, oceny i usuwania podatności.

Należy określić źródła informacji, sposób klasyfikacji podatności, terminy wdrażania poprawek, wyjątki, testy i zasady postępowania z systemami, których nie można szybko zaktualizować.

W firmie programistycznej proces powinien obejmować także zależności open source, obrazy kontenerów, biblioteki, pipeline’y CI/CD i sekrety przechowywane w repozytoriach.

Konieczne może być prowadzenie wykazu komponentów oprogramowania oraz monitorowanie informacji o nowych podatnościach.

Procedura powinna również określać sposób przyjmowania zgłoszeń o podatnościach od klientów i badaczy bezpieczeństwa.

Bezpieczne wytwarzanie oprogramowania

Software house objęty ustawą albo świadczący usługi podmiotom regulowanym powinien posiadać zasady bezpiecznego cyklu życia oprogramowania.

Dokumentacja może obejmować wymagania bezpieczeństwa, przeglądy kodu, testy automatyczne, skanowanie zależności, zarządzanie sekretami, separację środowisk, kontrolę wdrożeń i zatwierdzanie zmian.

Należy ograniczyć możliwość samodzielnego wdrożenia kodu produkcyjnego przez jedną osobę bez odpowiedniej kontroli, szczególnie w systemach krytycznych.

Proces powinien obejmować reagowanie na podatności odkryte po wydaniu produktu oraz zasady przekazywania klientom aktualizacji bezpieczeństwa.

Polityka kryptografii

Organizacja powinna ustalić, kiedy stosuje szyfrowanie danych w transmisji i w spoczynku, jak zarządza kluczami, certyfikatami i sekretami oraz kto może uzyskać do nich dostęp.

Nie wystarczy ogólne stwierdzenie, że firma stosuje nowoczesne szyfrowanie.

Dokument powinien uwzględniać generowanie, przechowywanie, rotację, unieważnianie i odzyskiwanie kluczy.

W środowiskach chmurowych należy ustalić, czy kluczami zarządza dostawca, klient czy sama firma.

Bezpieczeństwo personelu

Człowiek pozostaje jednym z najważniejszych elementów systemu bezpieczeństwa.

Firma powinna posiadać procedury związane z rekrutacją, nadawaniem dostępów, poufnością, szkoleniami, zmianą roli i zakończeniem współpracy.

Szkolenia nie powinny ograniczać się do jednorazowego przesłania prezentacji. Należy dokumentować udział, okresowo odnawiać wiedzę i dostosowywać materiały do roli.

Administratorzy, programiści, helpdesk i kierownictwo potrzebują innych treści. Osoba zarządzająca systemami klientów powinna znać procedury incydentowe, zasady kont uprzywilejowanych i sposoby reagowania na próby socjotechniczne.

Ustawa przewiduje również wymagania dotyczące osób realizujących określone zadania z zakresu bezpieczeństwa i obsługi incydentów. Osoba prawomocnie skazana za przestępstwa przeciwko ochronie informacji nie może realizować wskazanych w ustawie zadań. (ELI)

Dokumentacja techniczna

Ustawa wymienia dokumentację techniczną systemu informacyjnego jako element dokumentacji normatywnej. (ELI)

Powinna ona obejmować co najmniej architekturę, komponenty, przepływy danych, integracje, zależności, konfiguracje, zasady monitoringu i mechanizmy bezpieczeństwa.

Dokumentacja powinna być aktualizowana po zmianach. Nieaktualny diagram architektury może utrudnić obsługę incydentu i doprowadzić do pominięcia istotnego systemu.

W firmie zarządzającej środowiskiem klienta należy wyraźnie rozdzielić dokumentację własnej infrastruktury od dokumentacji powierzonych systemów.

Dokumentacja operacyjna

Najczęściej pomijanym obszarem są dowody wykonywania procedur.

Dokumentacją operacyjną mogą być raporty z przeglądów dostępów, wyniki skanów podatności, protokoły testów kopii zapasowych, raporty z ćwiczeń incydentowych, rejestry szkoleń, logi, zgłoszenia serwisowe, decyzje dotyczące ryzyka i raporty z audytów.

Ustawa wprost wskazuje, że dokumentacja operacyjna obejmuje zapisy potwierdzające wykonanie czynności wymaganych dokumentacją normatywną, w tym automatycznie generowane dzienniki systemów.

Firma powinna zaplanować, gdzie przechowuje takie dowody, kto je zatwierdza i jak długo pozostają dostępne.

Dokumentacja bezpieczeństwa musi być chroniona przed nieuprawnionym dostępem, uszkodzeniem, utratą i zmianą. Należy stosować wersjonowanie oraz ograniczać dostęp do osób upoważnionych. Ustawa wymaga także przechowywania wycofanej dokumentacji przez określony okres i udokumentowania jej zniszczenia.

Rola kierownictwa

NIS2 nie może zostać potraktowana jako zadanie wyłącznie działu IT albo administratora bezpieczeństwa.

Kierownictwo powinno uczestniczyć w zatwierdzaniu systemu zarządzania bezpieczeństwem, akceptowaniu ryzyka, zapewnianiu zasobów i nadzorowaniu wykonania obowiązków.

Zarząd powinien otrzymywać okresowe raporty dotyczące ryzyk, incydentów, audytów, podatności, ciągłości działania i dostawców.

Decyzje o akceptacji wysokiego ryzyka nie powinny być podejmowane wyłącznie przez administratora albo programistę.

Dokumentacja powinna wskazywać odpowiedzialność poszczególnych osób i sposób eskalacji problemów. Brak jasnego właściciela ryzyka często prowadzi do sytuacji, w której każdy zakłada, że zabezpieczenie powinien wdrożyć ktoś inny.

Czy trzeba zatrudnić specjalistę do spraw NIS2?

Ustawa nie wymaga, aby każda firma utworzyła stanowisko nazwane „pełnomocnikiem NIS2”.

Podmiot powinien jednak zapewnić osoby posiadające kompetencje potrzebne do realizacji obowiązków. Część zadań może być wykonywana przez pracowników, a część powierzona zewnętrznemu dostawcy.

Outsourcing nie przenosi całej odpowiedzialności. Firma nadal musi nadzorować wykonanie usług, podejmować decyzje i posiadać wiedzę pozwalającą ocenić otrzymywane raporty.

Ustawa przewiduje również wskazanie osób kontaktowych i korzystanie z systemu teleinformatycznego służącego współpracy w krajowym systemie cyberbezpieczeństwa.

Firma powinna unikać sytuacji, w której cała wiedza o bezpieczeństwie znajduje się u jednego zewnętrznego konsultanta, bez którego nie można obsłużyć incydentu ani odtworzyć dokumentacji.

Audyt bezpieczeństwa

Podmioty kluczowe podlegają obowiązkowi przeprowadzania audytów zgodności systemu zarządzania bezpieczeństwem informacji.

Podmioty spełniające przesłanki w dniu wejścia ustawy w życie powinny przeprowadzić pierwszy audyt w terminie dwudziestu czterech miesięcy od wejścia nowelizacji, czyli zasadniczo do 2 kwietnia 2028 r.

Nie oznacza to, że do tego czasu nie należy przeprowadzać żadnej kontroli. Przed ustawowym audytem warto wykonać analizę luk albo audyt gotowości.

Pozwala to ustalić, czy dokumentacja odpowiada praktyce, czy zabezpieczenia zostały wdrożone i czy organizacja posiada dowody ich działania.

Audyt wykonany tuż przed terminem może wykazać braki, których nie da się usunąć w krótkim czasie.

Kary za naruszenie obowiązków

Nowelizacja przewiduje administracyjne kary pieniężne zarówno dla podmiotów, jak i w określonych przypadkach dla kierowników.

Ustawodawca wprowadził jednak rozwiązanie przejściowe, zgodnie z którym nowe kary pieniężne wskazane w nowelizacji mogą być po raz pierwszy nakładane po upływie dwóch lat od wejścia ustawy w życie. Oznacza to zasadniczo datę 2 kwietnia 2028 r.

Nie oznacza to, że do tego dnia obowiązki mają charakter dobrowolny. Organy mogą podejmować działania nadzorcze, żądać informacji, kontrolować realizację obowiązków i nakazywać usunięcie naruszeń.

Brak kar w pierwszym okresie nie chroni również przed odpowiedzialnością cywilną, kontraktową, skutkami naruszenia RODO, utratą klientów ani konsekwencjami incydentu.

Dla firmy IT największym kosztem braku zgodności może nie być sama kara administracyjna, lecz utrata kontraktu z klientem regulowanym, który nie zaakceptuje dostawcy bez odpowiednich procedur i dowodów bezpieczeństwa.

Firmy nieobjęte bezpośrednio NIS2

Software house może nie być podmiotem kluczowym ani ważnym, a mimo to odczuwać skutki regulacji.

Klienci objęci ustawą muszą zarządzać bezpieczeństwem łańcucha dostaw. Będą więc wymagać od wykonawców informacji o zabezpieczeniach, procedurach incydentowych, podwykonawcach, lokalizacji danych, testach i ciągłości działania.

W nowych umowach mogą pojawiać się krótkie terminy zgłaszania incydentów, prawo audytu, obowiązek współpracy z CSIRT, wymagania dotyczące uwierzytelniania wieloskładnikowego, testów penetracyjnych i kontroli podwykonawców.

Firma, która formalnie pozostaje poza ustawą, może więc potrzebować znacznej części dokumentacji, aby utrzymać klientów z sektora finansowego, energetycznego, medycznego, transportowego albo administracji.

Warto odróżnić obowiązek ustawowy od obowiązku kontraktowego. Klient nie może automatycznie przenieść na małego dostawcę wszystkich swoich obowiązków, ale może wymagać zabezpieczeń proporcjonalnych do ryzyka usługi.

Jak rozpocząć wdrożenie?

Pierwszym krokiem powinna być analiza, czy firma rzeczywiście podlega ustawie.

Następnie należy określić zakres systemu zarządzania bezpieczeństwem informacji. Nie zawsze musi obejmować absolutnie całą organizację. Powinien jednak objąć systemy, ludzi, lokalizacje i dostawców związanych ze świadczeniem regulowanej usługi.

Kolejnym etapem jest inwentaryzacja aktywów, usług, procesów, danych, dostawców i dostępów.

Na tej podstawie można przeprowadzić analizę ryzyka i analizę luk pomiędzy stanem istniejącym a wymaganiami ustawy.

Dopiero później należy przygotowywać lub aktualizować polityki. Tworzenie dokumentów przed poznaniem architektury i ryzyka prowadzi do powstania procedur oderwanych od praktyki.

Wdrożenie powinno obejmować także zabezpieczenia techniczne, szkolenia, ćwiczenia, testy i zbieranie dowodów operacyjnych.

Minimalny pakiet dokumentacji

Zakres dokumentacji powinien być dostosowany do organizacji, ale firma objęta ustawą będzie zazwyczaj potrzebowała analizy kwalifikacyjnej, polityki bezpieczeństwa informacji, metodyki i rejestru ryzyka, inwentaryzacji aktywów, planu postępowania z ryzykiem, procedury zarządzania dostępem, procedury incydentowej, planu ciągłości działania, planu odtwarzania awaryjnego, procedury zarządzania podatnościami i aktualizacjami, zasad bezpieczeństwa dostawców, procedury tworzenia kopii zapasowych, zasad kryptografii, procedur bezpieczeństwa personelu oraz dokumentacji technicznej.

Pakiet powinien być uzupełniony o rejestry i dowody, takie jak ewidencja incydentów, raporty z przeglądów dostępów, testy odtworzenia, raporty z audytów, protokoły ćwiczeń, wyniki skanowania podatności, rejestry szkoleń i oceny dostawców.

Nie chodzi o to, aby każdy obszar znajdował się w osobnym pliku. Mała firma może połączyć kilka zagadnień w jednym dokumencie. Ważne jest, aby wszystkie wymagane kwestie zostały uregulowane i były stosowane.

Najczęstsze błędy firm IT

Pierwszym błędem jest założenie, że NIS2 dotyczy wszystkich firm technologicznych. Prowadzi to do wdrażania nadmiernej dokumentacji bez wcześniejszego ustalenia zakresu.

Drugim błędem jest przeciwne założenie, że software house na pewno nie podlega ustawie. Firma może w rzeczywistości świadczyć usługi zarządzane, nawet jeśli nie używa takiej nazwy w materiałach marketingowych.

Trzecim problemem jest skupienie się na dokumentach bez wdrożenia zabezpieczeń i procesów. Polityka istnieje, ale nikt nie wykonuje przeglądów, nie testuje kopii i nie rejestruje incydentów.

Kolejnym błędem jest powierzenie wdrożenia wyłącznie administratorowi IT. Cyberbezpieczeństwo obejmuje zarząd, HR, zakupy, prawników, sprzedaż, rozwój oprogramowania i zarządzanie dostawcami.

Często pomijana jest również dokumentacja operacyjna. Firma ma procedurę, ale nie potrafi udowodnić, że ją stosuje.

Ryzykowne jest także kopiowanie dokumentacji ISO albo RODO bez dostosowania do wymagań NIS2. Cele tych regulacji częściowo się pokrywają, ale nie są identyczne.

Podsumowanie

NIS2 nie obejmuje automatycznie każdej firmy informatycznej. Kluczowe znaczenie ma to, jakie usługi przedsiębiorca rzeczywiście świadczy, jak duża jest jego organizacja i czy mieści się w jednej z kategorii wskazanych w ustawie.

Największą uwagę powinny poświęcić regulacji firmy świadczące usługi zarządzane, zarządzane usługi cyberbezpieczeństwa, usługi chmurowe, centra danych, DNS, rejestrację domen, komunikację elektroniczną i inne usługi infrastruktury cyfrowej.

Software house, który jedynie tworzy i przekazuje kod, może pozostawać poza bezpośrednim zakresem. Jeżeli jednak administruje środowiskami klientów, utrzymuje ich systemy, zarządza kontami, kopiami, aktualizacjami i monitoringiem, powinien dokładnie zbadać status dostawcy usług zarządzanych.

Pierwszym dokumentem nie powinna być polityka bezpieczeństwa, lecz analiza kwalifikacyjna. Dopiero po ustaleniu zakresu należy budować system zarządzania bezpieczeństwem informacji.

Dokumentacja musi obejmować zarówno zasady, jak i dowody ich wykonywania. Sama polityka bez przeglądów, testów, raportów i logów nie zapewnia zgodności.

Firmy objęte ustawą powinny przygotować analizę ryzyka, plan postępowania z ryzykiem, inwentaryzację aktywów, procedurę incydentową, plany ciągłości i odtwarzania, zasady dostępów, kopii zapasowych, podatności, kryptografii, bezpiecznego rozwoju oraz zarządzania dostawcami.

Nawet przedsiębiorca pozostający poza ustawowym zakresem może potrzebować podobnych dokumentów. Klienci objęci NIS2 będą przenosić wymagania bezpieczeństwa do umów z dostawcami i żądać dowodów odporności łańcucha dostaw.

Nowelizacja obowiązuje od 2 kwietnia 2026 r., natomiast podmioty spełniające kryteria w tym dniu otrzymały zasadniczo dwanaście miesięcy na wdrożenie podstawowych obowiązków. Czas ten powinien zostać wykorzystany na rzeczywistą zmianę organizacji, a nie wyłącznie przygotowanie dokumentów przed kontrolą.