NIS2 w praktyce - jakie zabezpieczenia i procedury powinna wdrożyć firma?
W pierwszej części serii wyjaśniliśmy, czym jest NIS2 i które firmy mogą podlegać nowym wymaganiom. Jeżeli organizacja jest już na etapie przygotowań, pojawia się bardziej praktyczne pytanie: co właściwie trzeba zmienić w codziennym działaniu firmy?
NIS2 nie wskazuje jednego programu, firewalla czy gotowego pakietu zabezpieczeń. Wymaga podejścia opartego na ryzyku – środki techniczne, operacyjne i organizacyjne mają być odpowiednie do skali działalności i zagrożeń. W praktyce oznacza to uporządkowanie kilku obszarów, które często już istnieją w firmie, ale nie zawsze są spójne, regularnie sprawdzane lub dobrze udokumentowane.
Polska nowelizacja ustawy o Krajowym Systemie Cyberbezpieczeństwa obowiązuje od 3 kwietnia 2026 r. Podmioty, które w tym dniu spełniały kryteria podmiotu kluczowego lub ważnego, mają czas na wdrożenie głównych obowiązków do 3 kwietnia 2027 r. Ministerstwo Cyfryzacji opisuje ten harmonogram i zakres obowiązków na gov.pl.
1. Dostępy i konta - zacznij od tego, kto może zrobić co
W wielu firmach największym problemem nie jest brak zaawansowanego systemu bezpieczeństwa, ale zbyt szerokie uprawnienia. Pracownicy mają dostęp do zasobów, których już nie potrzebują, stare konta pozostają aktywne, a konta administracyjne są używane do zwykłej codziennej pracy.
Przy wdrożeniu NIS2 warto zacząć od zasady najmniejszych uprawnień. Każdy użytkownik powinien mieć dostęp tylko do tych danych i systemów, które są mu potrzebne do wykonywania obowiązków. Dostęp administracyjny powinien być ograniczony, a konta osób odchodzących z firmy wyłączane zgodnie z ustaloną procedurą.
Drugim elementem jest uwierzytelnianie wieloskładnikowe, czyli MFA. Szczególnie ważne jest ono dla poczty, usług chmurowych, VPN, kont administratorów i systemów dostępnych z Internetu. Samo silne hasło nie daje już wystarczającej ochrony, jeżeli zostanie przejęte w wyniku phishingu lub wycieku.
Jeżeli firma korzysta z domeny Windows, Active Directory lub Microsoft 365, warto przy okazji uporządkować grupy, role i polityki dostępu. Pomocny może być też przegląd zarządzania użytkownikami i dostępami, szczególnie jeśli środowisko rozwijało się przez kilka lat bez regularnego przeglądu uprawnień.
Jednym z obszarów wskazywanych w NIS2 jest ciągłość działania, w tym zarządzanie kopiami zapasowymi i odtwarzaniem po awarii. Z biznesowego punktu widzenia pytanie jest proste: ile czasu firma może pracować bez najważniejszych systemów i jak szybko jest w stanie je przywrócić?
Samo wykonywanie backupu nie daje jeszcze odpowiedzi. Trzeba wiedzieć, co jest kopiowane, jak długo przechowywane są dane, kto może usunąć kopie i czy część backupu jest odseparowana od środowiska produkcyjnego. W przypadku ransomware dostępna z tego samego konta kopia może zostać zaszyfrowana razem z serwerem.
Najważniejszym testem jest jednak odtworzenie. Firma powinna regularnie sprawdzać, czy z wykonanej kopii rzeczywiście można odzyskać pliki, bazę danych, maszynę wirtualną lub cały serwer. Dzięki temu problem wychodzi podczas kontrolowanego testu, a nie podczas realnej awarii.
W praktyce warto wprowadzić harmonogram testowania backupów i procedur odtwarzania danych oraz określić, które systemy muszą zostać przywrócone w pierwszej kolejności.
3. Aktualizacje, podatności i monitoring - bezpieczeństwo nie może działać tylko po awarii
Kolejnym praktycznym obszarem jest utrzymanie systemów. Komputery, serwery, urządzenia sieciowe, aplikacje i usługi chmurowe wymagają regularnych aktualizacji. Problem pojawia się wtedy, gdy w firmie nie ma jednej osoby lub zespołu odpowiedzialnego za sprawdzenie, czy aktualizacje rzeczywiście zostały wykonane.
Warto rozdzielić zwykłe aktualizacje od podatności krytycznych. Jeżeli producent publikuje informację o luce aktywnie wykorzystywanej przez atakujących, firma powinna mieć możliwość szybkiej oceny, czy dotyczy ona jej środowiska i jak szybko można wdrożyć poprawkę lub rozwiązanie tymczasowe.
Równie ważny jest monitoring. NIS2 nie zakłada, że każdy incydent można zatrzymać. Firma powinna jednak mieć szansę zauważyć nietypowe zdarzenia: wielokrotne nieudane logowania, nagłą zmianę konfiguracji, zatrzymanie usługi, brak backupu czy przeciążenie serwera. Im szybciej wykryty problem, tym łatwiej ograniczyć jego skutki.
Dla mniejszych organizacji nie zawsze oznacza to budowę własnego centrum bezpieczeństwa. Część zadań może być realizowana w ramach monitoringu i utrzymania infrastruktury IT, jeżeli zakres monitoringu i sposób reagowania są wcześniej jasno określone.
4. Procedura reagowania na incydent - co robimy w pierwszej godzinie?
Cyberincydent zwykle nie zaczyna się od komunikatu: „właśnie trwa atak”. Częściej pracownik zgłasza podejrzaną wiadomość, ktoś traci dostęp do plików, system zaczyna działać nietypowo albo administrator zauważa logowanie z nieznanego miejsca.
Dlatego procedura reagowania powinna być prosta i możliwa do wykorzystania również przez osoby nietechniczne. Pracownik musi wiedzieć, gdzie zgłosić podejrzane zdarzenie. Zespół techniczny powinien wiedzieć, kto podejmuje decyzję o odłączeniu urządzenia, zablokowaniu konta lub zatrzymaniu usługi. Kierownictwo powinno natomiast wiedzieć, kiedy sytuacja wymaga eskalacji i formalnego zgłoszenia.
Dobra procedura powinna obejmować przynajmniej identyfikację zdarzenia, zabezpieczenie dowodów i logów, ograniczenie skutków, przywrócenie usług oraz krótkie podsumowanie po incydencie. To ostatnie jest ważne, bo pozwala poprawić zabezpieczenia na podstawie realnego zdarzenia, a nie tylko teoretycznych scenariuszy.
W przypadku podmiotów objętych KSC znaczenie ma również raportowanie poważnych incydentów do właściwych podmiotów krajowego systemu cyberbezpieczeństwa. Właśnie dlatego organizacja powinna wcześniej ustalić, kto odpowiada za ocenę incydentu i komunikację zewnętrzną, zamiast podejmować te decyzje dopiero w sytuacji kryzysowej.
5. Dostawcy IT i łańcuch dostaw - bezpieczeństwo firmy nie kończy się na własnej sieci
Firma może mieć dobrze zabezpieczone komputery i serwery, a mimo to pozostawać podatna przez zewnętrznego dostawcę. Dotyczy to między innymi firm IT, dostawców oprogramowania, hostingu, chmury, systemów ERP, monitoringu czy serwisu posiadającego zdalny dostęp do infrastruktury.
NIS2 wskazuje bezpieczeństwo łańcucha dostaw jako jeden z elementów zarządzania ryzykiem. W praktyce nie chodzi o przesyłanie każdemu kontrahentowi wielostronicowej ankiety. Najpierw warto ustalić, którzy dostawcy mają rzeczywisty wpływ na kluczowe systemy i dane.
Dla takich podmiotów trzeba sprawdzić przede wszystkim zakres dostępu, sposób logowania, odpowiedzialność za aktualizacje, zasady zgłaszania incydentów oraz możliwość odebrania dostępu po zakończeniu współpracy. Dostęp serwisowy „na wszelki wypadek”, pozostawiony na lata bez kontroli, jest dokładnie takim ryzykiem, które warto usunąć.
Dobrze skonfigurowane zabezpieczenia są ważne, ale firma musi również wiedzieć, kto za nie odpowiada i jak sprawdza ich skuteczność. NIS2 obejmuje więc nie tylko technologię, ale też procesy, ludzi i odpowiedzialność kierownictwa.
Dokumentacja nie powinna być tworzona wyłącznie na potrzeby kontroli. Ma pomagać w codziennej pracy. Krótka lista właścicieli systemów, procedura nadawania dostępów, harmonogram testów backupu czy instrukcja zgłaszania incydentu mają znacznie większą wartość niż rozbudowany dokument, którego nikt w firmie nie używa.
Podobnie ze szkoleniami. Pracownik nie musi znać szczegółów ustawy o KSC. Powinien natomiast rozpoznawać typowe próby phishingu, wiedzieć, że nie należy akceptować nieoczekiwanych żądań MFA oraz umieć szybko zgłosić podejrzane zdarzenie. Kierownictwo powinno rozumieć ryzyka biznesowe i podejmować decyzje dotyczące priorytetów oraz zasobów.
Jak sprawdzić, czego brakuje w Twojej firmie?
Największy błąd przy wdrożeniu NIS2 to próba poprawiania wszystkiego jednocześnie. W większości firm część zabezpieczeń już działa. Problemem jest raczej brak spójności: backup jest, ale nie był testowany; MFA działa w Microsoft 365, ale nie na VPN; monitoring obejmuje serwer, ale nikt nie reaguje na alerty; dostawca ma zdalny dostęp, ale nikt nie wie, z jakiego konta korzysta.
Dlatego dobrym pierwszym krokiem jest audyt gotowości. Nie powinien kończyć się wyłącznie listą błędów. Jego wartością jest podział działań na priorytety: co trzeba poprawić natychmiast, co można zaplanować na kolejny etap i które rozwiązania już spełniają swoją funkcję.
W naszej pracy możemy zacząć od technicznego przeglądu środowiska – kont i uprawnień, backupów, serwerów, urządzeń sieciowych, Microsoft 365, zdalnego dostępu i monitoringu. Następnie można połączyć wyniki z wymaganiami organizacyjnymi i przygotować realny plan zmian. Dzięki temu wdrożenie NIS2 nie staje się projektem „kupmy wszystko od nowa”, tylko uporządkowaniem najważniejszych ryzyk firmy.
Najważniejszy efekt nie powinien polegać na zdobyciu dokumentu potwierdzającego zgodność. Firma powinna po prostu lepiej wiedzieć, co chroni, kto ma dostęp, jak wykrywa problem i co zrobi, kiedy któregoś dnia zabezpieczenia okażą się niewystarczające.
Krótka checklista przed dalszym wdrożeniem
- • Czy MFA jest włączone na najważniejszych kontach i usługach?
- • Czy uprawnienia użytkowników i administratorów są regularnie przeglądane?
- • Czy backup był testowo odtwarzany, a nie tylko wykonywany?
- • Czy firma monitoruje najważniejsze systemy i reaguje na alerty?
- • Czy istnieje prosta procedura zgłaszania i obsługi incydentu?
- • Czy zdalny dostęp dostawców jest kontrolowany i możliwy do szybkiego odebrania?
- • Czy wiadomo, kto odpowiada za kluczowe systemy i decyzje bezpieczeństwa?
- • Czy pracownicy wiedzą, jak zgłosić phishing lub podejrzane logowanie?
