NIS2 w praktyce dla MSP: checklista wdrożenia na 90 dni

NIS2 wymaga od części MSP wdrożenia proporcjonalnych środków cyberbezpieczeństwa oraz gotowości do zgłaszania „istotnych” incydentów w reżimie 24 h i 72 h. Da się to ogarnąć w 90 dni, jeśli potraktujesz temat jak projekt: scope, ryzyka, minimum techniczne, procedury i dowody.

 

Czy Twoja firma w ogóle podlega NIS2 i co to znaczy dla MSP?

NIS2 nie jest „dla wszystkich”. Dotyczy podmiotów z określonych sektorów i usług (m.in. energia, transport, zdrowie, bankowość, infrastruktura cyfrowa, dostawcy usług ICT, część produkcji itd.), a następnie dzieli je na „essential” i „important”. Każdy przypadek trzeba przejść przez dwie kratki: sektor oraz wielkość i rola w łańcuchu dostaw.

Praktycznie dla MSP oznacza to trzy rzeczy:

1. musisz umieć udowodnić, że zarząd świadomie nadzoruje cyberbezpieczeństwo (to jest część wymagań),
2. wdrażasz środki techniczne i organizacyjne „proporcjonalnie do ryzyka”,
3. masz proces zgłaszania incydentów i komunikacji do klientów, jeśli incydent może im zaszkodzić.

Jakie są twarde terminy i co jest pewnikiem, a co zależy od polskich przepisów?

Pewnik unijny: NIS2 to dyrektywa, więc państwa członkowskie wdrażają ją do prawa krajowego, a termin transpozycji był w październiku 2024.

Pewnik praktyczny: obowiązki, o które firmy potykają się najczęściej, są opisane w samej dyrektywie i są stabilne: wymagane obszary środków bezpieczeństwa (art. 21) oraz terminy raportowania incydentów (art. 23). (EUR-Lex)

Polski kontekst (ważne, bo to będzie „Twoja” kontrola): rząd przyjął projekt zmian ustawy o KSC 21.10.2025 i skierował go do Sejmu 7.11.2025. W komunikacie podano też skalę zgłoszeń do CSIRT NASK: ponad 39 tys. (2022), ponad 75 tys. (2023) i ponad 103 tys. (2024). To jest dobra amunicja do rozmowy z zarządem o ryzyku i budżecie. (Gov.pl)

Jak wygląda plan wdrożenia NIS2 w 90 dni, tydzień po tygodniu?

Poniżej masz plan „minimum zgodności + maksimum sensu”. To nie jest papierologia dla sportu. To plan, który realnie obniża ryzyko ransomware, wycieku i przestojów.

Dni 1–7: Ustal scope, właścicieli i mapę systemów

Cel: wiedzieć, co chronisz i kto za to odpowiada.

• Wyznacz właściciela NIS2 (najlepiej: IT Security Lead) i sponsora z zarządu.
• Zrób inwentaryzację: systemy krytyczne, dane, dostawcy, integracje, punkty zdalnego dostępu.
• Ustal klasy usług: co jest „krytyczne” (np. produkcja, obsługa zamówień, systemy finansowe).
• Zrób prostą mapę przepływu danych i zależności (kto od kogo zależy, także w chmurze).

Dowód na koniec tygodnia: lista aktywów + lista usług krytycznych + właściciele systemów.

Link wewnętrzny (pasuje semantycznie): „Zarządzanie tożsamością i dostępem: od MFA po passwordless”.

Dni 8–14: Ocena ryzyka i decyzja o „proporcjonalnym minimum”

Cel: dobrać środki adekwatne do ryzyka i budżetu, tak jak wymaga art. 21.

• Zrób warsztat ryzyka (2 godziny). Lista zagrożeń: ransomware, BEC, wyciek danych, awaria dostawcy, sabotaż kont uprzywilejowanych.
• Ustal priorytety: top 5 scenariuszy + plan redukcji ryzyka.
• Zatwierdzenie przez zarząd: nie technikalia, tylko decyzje o ryzyku i priorytetach.

Dowód: rejestr ryzyk + protokół zatwierdzenia przez zarząd.

Dni 15–30: Szybkie wygrane techniczne, które robią różnicę

Cel: zamknąć najczęstsze dziury bez „wielkiej rewolucji”.

Minimum, które najczęściej ratuje skórę MSP:

• MFA wszędzie, gdzie się da: poczta, VPN, panele chmury, systemy finansowe, narzędzia zdalne.
• Dostępy uprzywilejowane: oddzielne konta admin, zasada najmniejszych uprawnień, przegląd członkostw w grupach.
• Backup 3-2-1 i test odtwarzania (nie sam backup, tylko dowód, że działa). Art. 21 wprost mówi o ciągłości działania, backupach i DR.
• Aktualizacje i podatności: stały rytm patchowania, krytyczne CVE w pierwszej kolejności, prosta polityka wyjątków.
• Logi: zbieraj minimum do analizy incydentów (AD, M365/Google, firewall, VPN, EDR). Bez logów „nie wiesz, co się stało”.

Dowód: screeny lub eksporty ustawień MFA, raport z testu odtworzenia, lista kont admin i polityk, potwierdzenie retencji logów.

Link wewnętrzny: „Przygotowanie firmy na ransomware 2026”.

Dni 31–60: Procesy, procedury i szkolenia, czyli to, co kontrola lubi najbardziej

Cel: zbudować powtarzalność.

• Procedura obsługi incydentu: triage, eskalacja, izolacja, komunikacja, decyzje zarządu.
• Playbooki: ransomware, wyciek danych, kompromitacja poczty, awaria dostawcy chmury.
• Szkolenia: zarząd ma obowiązek „ogarnąć temat” i przejść szkolenie, a organizacja powinna regularnie szkolić pracowników.
• Ocena skuteczności środków: ustal KPI, np. czas wdrożenia krytycznych łatek, odsetek MFA, czas wykrycia incydentu.

Dowód: procedury + lista szkoleń + protokoły testu tabletop (symulacja incydentu).

Dni ni 61–90: Łańcuch dostaw, testy i gotowość raportowania

Cel: domknąć wymagania, które najczęściej wychodzą dopiero po incydencie.

• Dostawcy: oceń dostawców krytycznych, wymagaj minimalnych zabezpieczeń i ustal kanał alarmowy. Art. 21 mówi wprost o bezpieczeństwie łańcucha dostaw.
• Testy: skan podatności, podstawowy pentest lub przegląd konfiguracji kluczowych systemów.
• Monitoring: ustaw alerty i dyżur, choćby „biznesowy”, żeby 24 h raportowania było w ogóle realne.
• Finalny przegląd: audyt wewnętrzny „czy mamy dowody”.

Dowód: rejestr dostawców + wymagania bezpieczeństwa + raport z testów + instrukcja zgłaszania incydentów.

Link wewnętrzny: „Zero Trust w małej firmie: wdrożenie krok po kroku”.

Jak ustawić proces zgłaszania incydentów w praktyce?

W NIS2 kluczowe są terminy. Minimalny szkielet wygląda tak:

• do 24 godzin od „uzyskania wiedzy o istotnym incydencie” wysyłasz wstępne ostrzeżenie,
• do 72 godzin wysyłasz zgłoszenie incydentu z pierwszą oceną wpływu i wskaźnikami kompromitacji, jeśli są,
• potem raport końcowy w określonym trybie (NIS2 mówi o raporcie końcowym nie później niż miesiąc po zgłoszeniu).

Jak to wdrożyć w MSP bez kosmosu:

• Ustal definicję „istotnego incydentu” na potrzeby firmy (progi: przestój, utrata danych, wpływ na klientów, koszty).
• Zrób jedną kartę „Incident One Pager”: kto, gdzie dzwoni, co zbieramy, kto zatwierdza komunikację.
• Przećwicz raz na kwartał symulację 60 minut. Po tym zwykle wychodzą braki, których nie widać w Wordzie.

Jakie minimum techniczne daje największy efekt?

NIS2 wymienia obszary wprost: obsługa incydentów, ciągłość działania, bezpieczeństwo łańcucha dostaw, kryptografia, kontrola dostępu i zarządzanie aktywami, MFA, szkolenia.

Jeśli miałbym wskazać „top 6” dla MSP, które widzę od 15 lat w praktyce:

1. MFA na wszystko zdalne i administracyjne,
2. kopie zapasowe z testem odtworzenia,
3. segmentacja i ograniczenie ruchu lateralnego,
4. EDR albo chociaż sensowny AV + polityki hardeningu,
5. centralne logowanie najważniejszych źródeł,
6. kontrola kont uprzywilejowanych.

Dlaczego? Bo w realnych incydentach MSP przegrywa nie przez brak „super technologii”, tylko przez brak podstaw, które zatrzymują rozprzestrzenianie i skracają czas wykrycia.

Jak uniknąć typowych błędów MSP przy NIS2?

Najczęstsze wpadki:

• „Mamy politykę, więc jesteśmy zgodni” bez dowodów wdrożenia.
• Backup bez testu odtworzenia.
• MFA tylko na poczcie, a zdalny pulpit i panele administracyjne bez ochrony.
• Brak właściciela i decyzji zarządu, a NIS2 wymaga governance i szkolenia kierownictwa.
• Dostawcy krytyczni bez wymagań bezpieczeństwa, mimo że dyrektywa akcentuje łańcuch dostaw.

Kiedy warto włączyć SOC, audyt lub hardening?

Jeśli masz:

• usługi krytyczne działające 24/7,
• mały zespół IT bez dyżuru,
• środowisko hybrydowe (chmura + on-prem),
• presję na szybkie raportowanie incydentów,
  to monitoring i reagowanie robią się praktycznie nie opcją, tylko warunkiem wykonalności wymagań czasowych.

W treściach na blogu możesz to zagrać neutralnie, bez reklamy: „Jeśli chcesz zweryfikować konfigurację, zbudować monitoring lub przeprowadzić hardening, zrób to z zespołem, który potrafi dostarczyć dowody i procedury, a nie tylko ‘ustawić narzędzie’”.

Podsumowanie: gotowy zestaw dowodów na koniec 90 dni

Jeśli po 90 dniach masz:

• inwentaryzację aktywów i usług krytycznych,
• rejestr ryzyk i decyzje zarządu,
• MFA, backup z testem, podstawowe logowanie,
• procedurę incydentową i ćwiczenie tabletop,
• zasady dla dostawców,
  to jesteś w miejscu, w którym NIS2 przestaje być „straszakiem”, a staje się normalnym systemem zarządzania ryzykiem.