Analiza ryzyka NIS2 — jak zrobić to zgodnie z ustawą

Analiza ryzyka to pierwszy obowiązek, jaki NIS2 nakłada na podmioty kluczowe i ważne. Nie audyt. Nie technologia. Nie szkolenia. Najpierw musisz wiedzieć, co chronisz, przed czym chronisz i jakie konsekwencje poniesie firma, jeśli to zawiedzie. Reszta wymagań Artykułu 21 — monitoring, backup, ciągłość działania, szyfrowanie — wynika bezpośrednio z tego, co pokaże analiza.

Problem w tym, że większość firm robi analizę ryzyka raz, wkłada ją do segregatora i wraca do niej dopiero, gdy przychodzi audytor. To nie spełnia wymagań NIS2 i nie chroni przed realnymi zagrożeniami. W tym przewodniku pokazujemy, jak zrobić to poprawnie — z metodologią, matrycą 5×5, konkretnym planem i checklistą do samodzielnej oceny.

Czego wymaga NIS2 w zakresie analizy ryzyka

Artykuł 21 ust. 2 lit. a) Dyrektywy NIS2 mówi wprost: podmioty kluczowe i ważne muszą wdrożyć „polityki analizy ryzyka i bezpieczeństwa systemów informatycznych". W polskiej ustawie o krajowym systemie cyberbezpieczeństwa (KSC 2.0) to wymaganie zostało przeniesione jako obowiązek posiadania udokumentowanego, systematycznego procesu zarządzania ryzykiem.

Trzy słowa, które zmieniają wszystko:

• Udokumentowany — dokument musi istnieć, być podpisany przez zarząd i dostępny do wglądu audytora.
• Systematyczny — nie jednorazowy. Proces cykliczny z jasnym harmonogramem przeglądów.
• Proces — nie produkt. Nie kupujesz „analizy ryzyka" jako usługi jednorazowej. Budujesz proces, który żyje w firmie.

Kontekst: dlaczego ustawa wymaga ciągłości

Ustawa nie wskazuje konkretnej częstotliwości aktualizacji, ale motyw 79 preambuły NIS2 odnosi się do „zmieniającego się krajobrazu zagrożeń". W praktyce organy nadzoru (w Polsce: CSIRT NASK, CSIRT GOV, CSIRT MON, zależnie od sektora) oczekują:

• Aktualizacji rocznej — pełny przegląd całej matrycy ryzyka.
• Aktualizacji incydentalnej — po każdej istotnej zmianie: nowy system, akwizycja, incydent, zmiana regulacji, nowy dostawca krytyczny.
• Przeglądu kwartalnego — dla podmiotów kluczowych w sektorach energii, zdrowia, finansów, transportu.

Konsekwencje braku: kary do 10 mln EUR

Artykuł 34 NIS2 określa maksymalne kary administracyjne:

• Podmioty kluczowe: do 10 mln EUR lub 2% rocznego obrotu światowego (wyższa wartość).
• Podmioty ważne: do 7 mln EUR lub 1,4% rocznego obrotu światowego.

Brak udokumentowanej analizy ryzyka to nie jest drobna uchybienie. To jedno z pierwszych naruszeń, które audytor wykryje, i jedno z pierwszych, które uruchamia procedurę nakładania kary. Dodatkowo członek zarządu odpowiada osobiście za brak nadzoru nad zarządzaniem ryzykiem (Artykuł 20 NIS2 — szczegóły w naszym artykule o odpowiedzialności zarządu).

Dlaczego większość firm robi to źle

W audytach, które prowadzimy u klientów przygotowujących się do NIS2, powtarzają się cztery błędy. Każdy z nich dyskwalifikuje analizę ryzyka z perspektywy zgodności.

Błąd 1: Analiza jako „jednorazowy dokument w segregatorze"

Firma zleca analizę ryzyka zewnętrznej firmie, dostaje PDF na 80 stron, drukuje, wkłada do segregatora „Zgodność" i wraca do tego za dwa lata. Problem: krajobraz zagrożeń zmienia się miesiącami, nie latami. Ransomware Qilin z 2025 działa inaczej niż ransomware z 2023. Twoja analiza z 2024 nie uwzględnia aktualnych wektorów ataku.

Błąd 2: Brak udziału biznesu — tylko IT

Najczęstszy grzech: analiza ryzyka robiona przez jednego administratora IT, który wypełnia szablon „bo tak trzeba do ISO". Efekt: ryzyka technologiczne są identyfikowane (SQL injection, phishing), ale ryzyka biznesowe — nie. Co się stanie, jeśli stracimy dostęp do systemu CRM na 48 godzin? Ile kosztuje nas godzina przestoju produkcji? Kto jest kluczowym dostawcą, którego atak zatrzymuje nasz łańcuch?

NIS2 wymaga analizy w kontekście biznesowym. Artykuł 21 wymienia „ryzyka zakłócenia funkcjonowania usług" — a to może określić tylko lider biznesowy, nie IT.

Błąd 3: Brak aktualizacji po zmianach

Firma przejmuje inną spółkę. Nikt nie aktualizuje analizy ryzyka. Nowa spółka ma przestarzały Active Directory, niepatchowany SharePoint on-premise i brak MFA. Miesiąc później — incydent. Audyt pokazuje, że analiza ryzyka nie uwzględniała przejętych aktywów. Zarząd odpowiada osobiście.

Błąd 4: Brak powiązania z działaniami

Analiza identyfikuje 50 ryzyk. Z tego 12 jest oznaczonych jako „wysokie". Ale nie istnieje plan postępowania — nie ma właściciela, terminu, budżetu, metryki. Analiza to tylko diagnoza, nie leczenie. Audytor pyta: „Co zrobiliście z ryzykiem nr 7, oznaczonym jako krytyczne w zeszłym roku?". Cisza.

Metodologia analizy ryzyka według NIS2

NIS2 nie narzuca konkretnej metodologii, ale w praktyce wszystkie poprawne podejścia mają ten sam szkielet pięciu kroków.

5 kroków analizy ryzyka

1. Inwentaryzacja aktywów — co mamy i co jest dla nas krytyczne (dane, systemy, procesy, ludzie, lokalizacje, dostawcy).
2. Identyfikacja zagrożeń — co może pójść nie tak (ransomware, phishing, awaria sprzętu, pożar, odejście kluczowego pracownika, atak na dostawcę).
3. Ocena podatności — jak bardzo jesteśmy wrażliwi na dane zagrożenie (brak MFA, nieaktualne systemy, brak szkoleń).
4. Oszacowanie ryzyka — prawdopodobieństwo × skutek. To właśnie tutaj używa się matrycy 5×5.
5. Plan postępowania — co robimy z ryzykiem (unikaj, redukuj, transferuj, akceptuj) i kto za to odpowiada.

Standardy i metodologie

ISO 31000:2018 — Risk Management Norma ogólna, niezwiązana z IT. Opisuje zasady, ramy i proces zarządzania ryzykiem w organizacji. Najlepsza do pokrycia całego obszaru firmy (nie tylko IT). Wada: wymaga „tłumaczenia" na konkretne ryzyka cyber.

NIST Cybersecurity Framework 2.0 (2024) Amerykański standard rozszerzony w 2024 o funkcję „Govern" (zarządzanie). Operacyjny, praktyczny, z konkretnymi kontrolami. Idealny do powiązania analizy ryzyka z codzienną pracą SOC i zespołu IT. Mapuje się bezpośrednio na wymagania NIS2 Art. 21.

ISO/IEC 27005:2022 — Information Security Risk Management Norma IT-specific, część rodziny ISO 27000. Najlepsza, jeśli firma ma już ISO 27001 — analiza ryzyka integruje się z SZBI. Szczegółowa, ale ciężka do wdrożenia w mniejszych organizacjach.

Jak wybrać metodologię dla swojej firmy

W SecIQ stosujemy hybrydę ISO 31000 + NIST CSF 2.0 — ISO daje ramę procesu, NIST dostarcza operacyjnych kontroli. Dopasowujemy ją do branży i dojrzałości klienta. Więcej o mapowaniu ISO 27001 na wymagania NIS2 w osobnym artykule.

Matryca ryzyka 5×5 w praktyce

Matryca 5×5 to standardowe narzędzie oceny ryzyka. Dwie osie: prawdopodobieństwo (jak często zdarzenie może wystąpić) i skutek (jak bardzo nas boli, gdy wystąpi). Każda oś ma skalę 1-5.

Skala prawdopodobieństwa

Skala skutku

Interpretacja wyników

Mnożenie prawdopodobieństwa × skutek daje wartość ryzyka od 1 do 25. Tradycyjna interpretacja:

• 1-4 (zielone) — akceptuj. Monitoruj okresowo.
• 5-9 (żółte) — monitoruj. Rozważ redukcję, jeśli koszt jest niski.
• 10-15 (pomarańczowe) — redukuj. Plan działań z terminem i właścicielem.
• 16-25 (czerwone) — unikaj lub redukuj natychmiast. Eskalacja do zarządu.

Przykład: scenariusz ransomware w średniej firmie produkcyjnej

Firma zatrudnia 250 osób, ma zakład produkcyjny i biuro. Nie ma SOC 24/7, ma antywirus i backupy na NAS w tej samej sieci.

• Zagrożenie: ransomware szyfrujący serwery produkcyjne i backupy.
• Prawdopodobieństwo: 4 (wysokie) — branża MŚP jest głównym celem operatorów ransomware w 2026, wektor wejścia przez phishing jest częsty, MFA tylko na 60% kont.
• Skutek: 5 (katastrofalny) — przestój produkcji 5-10 dni, straty > 10 mln PLN, utrata zaufania klientów, możliwa utrata kontraktu z głównym odbiorcą.
• Wartość ryzyka: 4 × 5 = 20 (czerwone).

Działania: wdrożenie MFA na wszystkich kontach (redukcja prawdopodobieństwa do 2), izolacja backupów offline (redukcja skutku do 3), monitoring SOC 24/7 (redukcja skutku do 2). Po działaniach: 2 × 2 = 4 (zielone).

To jest sens matrycy — nie „skatalogować ryzyka", tylko pokazać, co zrobić i jak zmieni się obraz po działaniach.

Inwentaryzacja aktywów — podstawa analizy

Nie można chronić tego, czego nie znasz. Inwentaryzacja aktywów to krok zerowy — bez niej analiza ryzyka jest fikcją.

Co zaliczamy do aktywów

• Dane — bazy klientów, dane pracowników, dane finansowe, własność intelektualna, tajemnica przedsiębiorstwa, dane osobowe (RODO).
• Systemy — serwery, stacje robocze, aplikacje SaaS (Microsoft 365, Salesforce), urządzenia sieciowe, OT/ICS w produkcji, urządzenia IoT.
• Procesy — sprzedaż, produkcja, księgowość, HR, obsługa klienta, łańcuch dostaw.
• Ludzie — kluczowi specjaliści, administratorzy, członkowie zarządu, osoby z dostępem do danych krytycznych.
• Lokalizacje — siedziba, oddziały, data center, biura zdalne.
• Dostawcy — kluczowi dostawcy IT, dostawcy usług chmurowych, operatorzy telekomunikacyjni, firmy outsourcingowe.

NIS2 Art. 21 ust. 2 lit. d) wymaga wprost zarządzania ryzykiem łańcucha dostaw — dlatego dostawcy są częścią inwentaryzacji.

Narzędzia do inwentaryzacji

Praktyczna rada: zacznij od arkusza. Zrób go kompletnym. Potem przenieś do narzędzia. Narzędzie bez poprawnej inwentaryzacji to tylko drogie puste pole.

Klasyfikacja aktywów

Każdy zasób przypisujemy do jednej z trzech kategorii:

• Krytyczny — utrata powoduje zatrzymanie działalności lub poważne konsekwencje prawne/finansowe. Np. ERP, dane klientów, systemy produkcyjne.
• Ważny — utrata powoduje znaczne zakłócenia, ale firma może funkcjonować przez 24-72 godziny. Np. CRM, systemy HR, portal klienta.
• Pomocniczy — utrata jest uciążliwa, ale nie krytyczna. Np. systemy wewnętrznej komunikacji, narzędzia projektowe.

Tagowanie według wymagań NIS2

Jeśli firma podlega NIS2, dodajemy dwa dodatkowe tagi:

• Typ podmiotu — kluczowy (Annex I) lub ważny (Annex II). Różnica: wyższe kary, krótsze terminy raportowania, bardziej rygorystyczny nadzór dla kluczowych.
• Usługa w zakresie NIS2 — które aktywa wspierają świadczenie usługi objętej dyrektywą. To właśnie te aktywa podlegają najściślejszej kontroli.

Szczegóły, kto podlega NIS2, w osobnym artykule.

Plan postępowania z ryzykiem

Analiza bez planu to biurokracja. Dla każdego zidentyfikowanego ryzyka wybieramy jedną z czterech strategii.

4 strategie postępowania

1. Unikanie — rezygnujemy z aktywności generującej ryzyko. Przykład: rezygnacja z przechowywania danych kart kredytowych i przekazanie obsługi płatności do PCI-DSS compliant providera.
2. Redukcja — wdrażamy kontrole zmniejszające prawdopodobieństwo lub skutek. Przykład: MFA (redukcja prawdopodobieństwa phishingu), backup offline (redukcja skutku ransomware), SOC 24/7 (redukcja skutku każdego incydentu przez szybkie wykrycie).
3. Transfer — przenosimy ryzyko na stronę trzecią. Przykład: ubezpieczenie cyber, outsourcing SOC, SLA u dostawcy chmury.
4. Akceptacja — świadoma decyzja zarządu, że ryzyko jest akceptowalne. Dokumentujemy w rejestrze z podpisem członka zarządu.

Priorytetyzacja: co redukować najpierw

Reguła: high probability + high impact first. Konkretnie:

1. Ryzyka z matrycy 5×5 o wartości 16-25 (czerwone) — natychmiast.
2. Ryzyka 10-15 (pomarańczowe) — plan w ciągu 3 miesięcy.
3. Ryzyka 5-9 (żółte) — rozważyć, jeśli koszt jest niski.
4. Ryzyka 1-4 (zielone) — akceptacja i monitoring.

Budżet: ile wydawać na redukcję ryzyka

Prosta zasada: koszt kontroli nie powinien przekraczać wartości chronionego aktywa ani wartości oczekiwanej straty. Przykład:

• Ryzyko ransomware dla firmy produkcyjnej: wartość ryzyka 20, oczekiwana strata 10 mln PLN.
• Inwestycja w SOC + MFA + backup offline: 500 tys. PLN rocznie.
• Po działaniach: wartość ryzyka 4, oczekiwana strata 500 tys. PLN.
• Oszczędność: 9 mln PLN rocznie przy inwestycji 500 tys. PLN. ROI oczywisty.

Szczegółowa kalkulacja ROI w artykule o karach NIS2 vs koszt SOC.

Monitoring: KPI i metryki skuteczności

Plan postępowania musi mieć metryki, żeby można go było weryfikować:

• MTTD (Mean Time To Detect) — średni czas wykrycia incydentu. Cel: < 15 minut dla krytycznych.
• MTTR (Mean Time To Respond) — średni czas reakcji. Cel: < 1 godzina dla krytycznych.
• % kont z MFA — cel: 100% dla kont administracyjnych, > 95% dla użytkowników.
• % systemów z aktualnymi patchami — cel: > 95% w ciągu 30 dni od wydania.
• % pracowników po szkoleniu phishing — cel: 100% rocznie, symulacje co kwartał.

Jak SecIQ podchodzi do analizy ryzyka

W SecIQ analiza ryzyka to nie jednorazowy dokument. To proces prowadzony przez dedykowanego vCISO, który zna Twoją firmę i wraca do niej regularnie.

Dedykowany vCISO prowadzi proces

vCISO (Virtual Chief Information Security Officer) to doświadczony specjalista bezpieczeństwa przypisany do Twojej firmy. Nie anonimowy konsultant z helpdesku — osoba, która zna strukturę organizacyjną, procesy biznesowe, kluczowych dostawców i historię incydentów. To ta sama osoba, która towarzyszy zarządowi podczas audytu NIS2.

Warsztat 2-dniowy z zarządem i liderami

Start analizy to warsztat stacjonarny lub zdalny z kluczowymi osobami:

• Dzień 1 (4 godz.): inwentaryzacja aktywów biznesowych z perspektywy liderów (nie IT). Co jest krytyczne dla działania firmy? Co nas zatrzyma? Kto jest kluczowym dostawcą?
• Dzień 2 (4 godz.): identyfikacja zagrożeń specyficznych dla branży, ocena matrycą 5×5, ustalenie priorytetów, mapowanie na wymagania NIS2 Art. 21.

Wynik: matryca ryzyka + plan postępowania + harmonogram wdrożenia, podpisane przez zarząd.

Matryca ryzyka dostosowana do branży

Nie używamy jednego szablonu dla wszystkich. Firma produkcyjna ma ryzyka OT/ICS, których nie ma kancelaria prawna. Szpital ma ryzyka związane z danymi medycznymi (RODO + NIS2 + ustawa o prawach pacjenta). SaaS ma ryzyka łańcucha dostaw i bezpieczeństwa API. Matryca dopasowana do branży to matryca, która wychwytuje realne zagrożenia, a nie tylko generyczne.

Ciągła aktualizacja w ramach usługi

vCISO w pakiecie SecIQ to nie projekt zamknięty po 2 dniach warsztatu. To:

• Przegląd kwartalny matrycy ryzyka.
• Aktualizacja po każdym istotnym zdarzeniu (incydent, nowy system, akwizycja, zmiana regulacji).
• Raportowanie do zarządu raz na kwartał — w formie zrozumiałej dla biznesu, nie technicznej.
• Wsparcie podczas audytu NIS2 — vCISO rozmawia z audytorem w imieniu klienta.

Więcej o usłudze vCISO: /uslugi/vciso. Jeśli chcesz zobaczyć, jak to wygląda w praktyce, umów 15-minutową rozmowę z naszym vCISO.

Checklist — samodzielna ocena dojrzałości

Odpowiedz szczerze na 10 pytań. Każde: TAK / NIE + komentarz (co konkretnie macie, co brakuje).

1. Czy macie udokumentowaną politykę analizy ryzyka podpisaną przez zarząd?
2. Czy analiza ryzyka była aktualizowana w ciągu ostatnich 12 miesięcy?
3. Czy w analizie brali udział liderzy biznesowi (nie tylko IT)?
4. Czy macie kompletną inwentaryzację aktywów krytycznych (dane, systemy, dostawcy)?
5. Czy używacie matrycy ryzyka (np. 5×5) z jasną skalą prawdopodobieństwa i skutku?
6. Czy dla każdego ryzyka wysokiego macie przypisanego właściciela i termin działania?
7. Czy ryzyka łańcucha dostaw są częścią analizy (zgodnie z NIS2 Art. 21 ust. 2 lit. d)?
8. Czy macie proces aktualizacji po istotnych zmianach (nowy system, incydent, akwizycja)?
9. Czy macie zdefiniowane KPI bezpieczeństwa (MTTD, MTTR, % MFA) i raportujecie je do zarządu?
10. Czy zarząd otrzymuje kwartalny raport o stanie ryzyka w zrozumiałej formie biznesowej?

Interpretacja wyników

• 0-3 TAK — krytyczne. Firma nie spełnia podstawowych wymagań NIS2 Art. 21. Ryzyko kary i odpowiedzialności zarządu. Natychmiast zacznij proces formalnej analizy ryzyka.
• 4-7 TAK — do poprawy. Podstawy są, ale proces ma luki. Prawdopodobnie brakuje udziału biznesu, aktualizacji lub powiązania z działaniami. W razie audytu zostaną wskazane niezgodności.
• 8-10 TAK — dobry poziom. Proces jest dojrzały. Skup się na ciągłej aktualizacji, metrykach i gotowości na audyt. Rozważ rozszerzenie o analizę scenariuszową i testy BCP.

Jeśli wynik to 0-7 TAK, warto porozmawiać z vCISO, który pomoże wyprostować proces w ciągu 4-6 tygodni. Umów rozmowę — pierwsze 15 minut bez zobowiązań.

Następne kroki

Analiza ryzyka to fundament, ale tylko pierwszy element wymagań NIS2. Jeśli masz już analizę, kolejne kroki to:

• Wdrożenie NIS2 krok po kroku — pełny plan wdrożenia wymagań Art. 21.
• Mapowanie NIS2 na ISO 27001 — jak wykorzystać istniejące SZBI.
• Odpowiedzialność zarządu za NIS2 — co konkretnie grozi członkom zarządu.
• NIS2 — wymagania i terminy 2026 — hub z pełnym kontekstem regulacyjnym.

Źródła

• Dyrektywa NIS2 (UE) 2022/2555 — EUR-Lex — oficjalny tekst dyrektywy, Artykuł 21 (wymagania środków zarządzania ryzykiem) i Artykuł 34 (kary).
• ISO 31000:2018 — Risk Management Guidelines — międzynarodowy standard zarządzania ryzykiem.
• NIST Cybersecurity Framework 2.0 (2024) — amerykański framework z nową funkcją „Govern".
• ISO/IEC 27005:2022 — Information Security Risk Management — norma ISO dla ryzyka IT.
• CERT Polska — Rekomendacje NIS2 — praktyczne wskazówki dla polskich podmiotów.
• Krajowy System Cyberbezpieczeństwa — gov.pl — oficjalne informacje o KSC 2.0 i implementacji NIS2 w Polsce.