Praktyczne przewodniki po regulacjach cyberbezpieczeństwa i wymaganiach zgodności dla firm działających w Polsce i Unii Europejskiej. Wyjaśniamy NIS2, ustawę o KSC, DORA, Cyber Resilience Act, ISO/IEC 27001, NIST Cybersecurity Framework oraz powiązane obowiązki w prosty, biznesowy sposób.
NIS2 vs ISO 27001: jak połączyć wymagania w jeden praktyczny plan
NIS2 i ISO 27001 nie powinny być dwoma oddzielnymi projektami. NIS2 określa obowiązki regulacyjne: zarządzanie ryzykiem cyber, zgłaszanie incydentów, nadzór zarządu, bezpieczeństwo dostawców i ciągłość działania. ISO 27001 daje system zarządzania, który pomaga te obowiązki uporządkować: zakres, ryzyka, Deklaracja Stosowania, kontrole, audyty, przeglądy zarządzania i działania korygujące. Najlepsze podejście to jedna mapa wymagań, jeden rejestr ryzyk, jedna roadmapa działań i jedno repozytorium dowodów.
Opracowanie: Zespół redakcyjny CCyber
NIS2 i ISO 27001 najlepiej połączyć w jeden praktyczny plan, a nie prowadzić jako dwa równoległe projekty. NIS2 mówi, jakie obowiązki regulacyjne firma musi spełnić: zarządzanie ryzykiem cyber, środki techniczne i organizacyjne, zgłaszanie incydentów, nadzór zarządu, bezpieczeństwo dostawców, ciągłość działania i dowody zgodności. ISO 27001 daje sposób zarządzania tymi obowiązkami: zakres, politykę bezpieczeństwa, ocenę ryzyka, plan postępowania z ryzykiem, Deklarację Stosowania, audyty wewnętrzne, przeglądy zarządzania i działania korygujące. Wspólny plan powinien mieć jedną analizę podlegania, jeden rejestr ryzyk, jedną mapę kontroli, jedną roadmapę, jedną macierz dowodów i jeden raport dla zarządu.
Lipiec 2026
NIS2 i ISO 27001 często są omawiane razem, ale nie są tym samym. Najprostsze rozróżnienie brzmi: NIS2 mówi, że określone organizacje muszą spełnić wymagania cyberbezpieczeństwa wynikające z prawa. ISO 27001 mówi, jak zbudować system zarządzania bezpieczeństwem informacji, który pozwala zarządzać ryzykiem w sposób uporządkowany, audytowalny i powtarzalny.
Dlatego najlepsze podejście nie brzmi „NIS2 albo ISO 27001”. Lepsze pytanie brzmi: jak wykorzystać ISO 27001 jako system zarządzania, który pomoże spełnić i udowodnić wymagania NIS2.
Nie automatycznie. Certyfikat ISO 27001 może być bardzo silnym dowodem dojrzałości organizacji, ale nie oznacza sam z siebie pełnej zgodności z NIS2. Powody są proste.
Firma nadal musi sprawdzić, czy podlega NIS2, w jakim kraju, w jakim sektorze, w jakiej roli i czy jest podmiotem kluczowym albo ważnym.
Szczegóły wdrożenia NIS2 wynikają z prawa krajowego. W Polsce trzeba sprawdzać aktualne przepisy związane z krajowym systemem cyberbezpieczeństwa.
NIS2 ma konkretne wymagania raportowania incydentów. Firma musi mieć procedurę i szablony dla pierwszych godzin incydentu.
Certyfikat może obejmować tylko część organizacji. Jeżeli zakres ISO 27001 nie obejmuje usług krytycznych, systemów regulowanych albo dostawców istotnych dla NIS2, trzeba go rozszerzyć lub uzupełnić osobnym mapowaniem.
Największą wartość daje wtedy, gdy obejmuje realne ryzyka, aktualne aktywa, dostawców, incydenty, testy, audyty i działania korygujące. Sam certyfikat bez aktualnych dowodów może nie wystarczyć w audycie NIS2.
Najlepszy model to warstwowe podejście: NIS2 jako warstwa obowiązków regulacyjnych, ISO 27001 jako warstwa systemu zarządzania, ISO 27002 jako warstwa kontroli i dowody jako warstwa audytowa.
Najważniejszym narzędziem praktycznym jest mapa wymagań. To tabela, która pokazuje, które wymaganie NIS2 jest obsługiwane przez który element ISO 27001, jaką kontrolę stosuje firma i jaki dowód potwierdza działanie.
Obszar NIS2: obsługa incydentów.
Element ISO 27001: planowanie, działanie, ocena skuteczności, działania korygujące.
Kontrole: procedura incident response, logi, role, eskalacja, ćwiczenie.
Dowody: plan reagowania, raport tabletop, rejestr incydentów, lista działań naprawczych.
NIS2 wymaga odpowiedzi, czy firma podlega regulacji. ISO 27001 wymaga określenia zakresu systemu zarządzania bezpieczeństwem informacji. Te dwa działania trzeba połączyć.
Dowody: analiza podlegania, zakres systemu zarządzania, mapa usług krytycznych, decyzja zarządu.
NIS2 podkreśla odpowiedzialność kierownictwa za zatwierdzanie i nadzór nad środkami zarządzania ryzykiem cyber. ISO 27001 wymaga przywództwa, ról, odpowiedzialności i przeglądu zarządzania.
Dowody: protokoły zarządu, raporty ryzyka, decyzje budżetowe, przegląd zarządzania.
To wspólny rdzeń NIS2 i ISO 27001. Bez rejestru ryzyk firma nie pokaże, dlaczego wdrożyła określone kontrole i czy są proporcjonalne.
Dowody: metodyka ryzyka, rejestr ryzyk, plan postępowania z ryzykiem, decyzje o akceptacji ryzyka.
Deklaracja Stosowania w ISO 27001 może stać się główną mapą kontroli dla NIS2, jeśli zostanie rozszerzona o wymagania regulacyjne.
Dowody: Deklaracja Stosowania, mapa NIS2, lista kontroli, status wdrożenia.
ISO 27001 porządkuje zarządzanie incydentami. NIS2 dodaje konkretne obowiązki zgłaszania istotnych incydentów w krótkich terminach.
Dowody: procedura incydentowa, szablony zgłoszeń, raport z ćwiczenia, rejestr incydentów.
NIS2 wymaga ciągłości działania i odtwarzania po incydencie. ISO 27001 pomaga to włączyć do systemu zarządzania, testów i audytów.
Dowody: plan ciągłości działania, raport backupu, raport testu odtworzenia, lista działań po teście.
NIS2 mocno podkreśla ryzyko dostawców. ISO 27001 i ISO 27002 pomagają uporządkować relacje z dostawcami, wymagania umowne i przeglądy.
Dowody: rejestr dostawców, oceny ryzyka, umowy, access review dostawców, plan wyjścia.
Kontrola dostępu jest jednym z najważniejszych obszarów dla NIS2 i ISO 27001. Przejęcie konta administratora może zniszczyć cały program bezpieczeństwa.
Dowody: raport MFA, lista administratorów, raport access review, checklisty offboardingu.
NIS2 wskazuje obsługę podatności i bezpieczeństwo nabywania, rozwoju oraz utrzymania systemów. ISO 27001 pomaga osadzić te działania w procesie ryzyka, zmian i dowodów.
Dowody: raport podatności, lista działań naprawczych, retest, akceptacje ryzyka.
NIS2 wymaga świadomości i odpowiedzialności zarządu. ISO 27001 wymaga kompetencji, świadomości, audytów wewnętrznych, przeglądów zarządzania i działań korygujących.
Dowody: plan szkoleń, listy uczestników, audyty wewnętrzne, przegląd zarządzania, rejestr działań korygujących.
Ustal, czy firma podlega NIS2, w jakim sektorze, w jakiej roli i w jakim kraju. W Polsce sprawdź aktualne przepisy krajowe związane z KSC.
Wynik: raport podlegania i decyzja zarządu.
Określ, czy obecny lub planowany zakres ISO 27001 obejmuje wszystkie usługi, systemy, lokalizacje i dostawców istotnych dla NIS2.
Wynik: zakres systemu zarządzania i mapa usług krytycznych.
Porównaj wymagania NIS2 z obecnym stanem ISO 27001, kontrolami, procedurami i dowodami.
Wynik: analiza luk z priorytetami.
Zbuduj wspólny rejestr ryzyk cyber. Nie twórz osobnego rejestru dla NIS2 i osobnego dla ISO 27001.
Wynik: rejestr ryzyk z właścicielami, wpływem, kontrolami i planem działań.
Dodaj do Deklaracji Stosowania kolumny: wymaganie NIS2, właściciel, dowód, status, luka i działanie naprawcze.
Wynik: Deklaracja Stosowania jako mapa kontroli NIS2 i ISO 27001.
Ustal działania na 30, 60, 90 dni i 12 miesięcy. Priorytet powinny mieć luki, które ograniczają największe ryzyko i są najważniejsze dla audytu.
Wynik: roadmapa z terminami, właścicielami i budżetem.
Uzupełnij najważniejsze procedury: incydenty, zgłaszanie, backup, dostęp, dostawcy, podatności, szkolenia i działania korygujące.
Wynik: zestaw procedur stosowanych w praktyce.
Przeprowadź test odtworzenia, ćwiczenie incydentu, przegląd uprawnień i test ścieżki zgłoszeniowej.
Wynik: raporty testów, lista luk i działania naprawcze.
Oceń dostawców krytycznych, uzupełnij wymagania bezpieczeństwa w umowach i sprawdź dostęp dostawców.
Wynik: rejestr dostawców, oceny ryzyka i plan poprawy.
Przeszkol zarząd i pracowników. Szkolenia powinny dotyczyć nie tylko wiedzy, ale też decyzji i zachowań.
Wynik: materiały, lista uczestników i wyniki testów.
Zbuduj jedno repozytorium dowodów dla NIS2, ISO 27001, KSC, audytów klientów i cyberubezpieczenia.
Wynik: macierz dowodów z datami, właścicielami i statusem.
Wykonaj audyt wewnętrzny, zamknij niezgodności i przygotuj przegląd zarządzania, który obejmuje zarówno ISO 27001, jak i NIS2.
Wynik: raport audytu, rejestr działań korygujących i protokół przeglądu zarządzania.
Największym błędem jest tworzenie dwóch oddzielnych bibliotek: jednej dla NIS2, drugiej dla ISO 27001. To zwiększa chaos, koszty i ryzyko niespójności.
Nie twórz nowego dokumentu, jeśli możesz rozszerzyć istniejący dokument o zakres, właściciela, dowód i mapowanie do wymagań.
Macierz dowodów pokazuje, czy firma potrafi udowodnić działanie kontroli. To szczególnie ważne, bo NIS2 i ISO 27001 wymagają nie tylko deklaracji, ale także powtarzalności, nadzoru i doskonalenia.
Jedna osoba prowadzi NIS2, druga ISO 27001, a dokumenty, ryzyka i dowody nie są ze sobą połączone. Efekt to duplikacja, niespójność i zmęczenie organizacji.
ISO 27001 pomaga, ale nie zastępuje analizy podlegania, krajowych obowiązków, terminów zgłaszania incydentów i wymagań sektorowych.
Tabela kontroli wygląda dobrze, ale firma nie potrafi pokazać raportu MFA, testu restore, access review albo ćwiczenia incydentu.
Certyfikat obejmuje centralę albo wybrany proces, ale NIS2 dotyczy usługi, systemu, spółki albo dostawcy poza zakresem.
Firma ma procedurę incident response, ale nie ma szablonów i ścieżki dla obowiązków NIS2: wczesne ostrzeżenie, zgłoszenie i raport końcowy.
Dokumentacja jest tworzona przez IT lub compliance, ale zarząd nie zatwierdza ryzyk, budżetu, wyjątków i priorytetów.
ISO i NIS2 wymagają kontroli relacji z dostawcami, ale firma nie ma rejestru dostawców krytycznych ani oceny ryzyka.
Firma sprawdza ISO 27001 oddzielnie, ale nie testuje, czy ten sam system dowodów odpowiada na wymagania NIS2.
Firma SaaS ma certyfikat ISO 27001 dla platformy i zespołu technicznego. Po wejściu wymagań NIS2 klienci zaczynają pytać o zgłaszanie incydentów, dostawców, ciągłość działania, podatności i odpowiedzialność zarządu. Firma początkowo traktuje NIS2 jako osobny projekt prawny.
Po analizie okazuje się, że większość elementów już istnieje w systemie ISO 27001, ale brakuje mapowania do NIS2, szablonów zgłoszeń 24 i 72 godziny, formalnej oceny kilku dostawców, dowodów szkolenia zarządu i raportu gotowości. Firma nie tworzy drugiej dokumentacji. Rozszerza Deklarację Stosowania, aktualizuje rejestr ryzyk, dodaje macierz dowodów i włącza NIS2 do przeglądu zarządzania.
Po 90 dniach firma ma jeden wspólny plan: NIS2 jako warstwa wymagań, ISO 27001 jako system zarządzania, ISO 27002 jako katalog kontroli i jedno repozytorium dowodów. Klienci dostają spójne odpowiedzi, a zarząd widzi realny status ryzyka.
ccyber.io pomaga firmom połączyć NIS2 i ISO 27001 w jeden praktyczny plan działań. Nie tworzymy dwóch równoległych projektów. Budujemy wspólne mapowanie wymagań, rejestr ryzyk, roadmapę, Deklarację Stosowania, procedury i repozytorium dowodów.
Możemy wesprzeć organizację w obszarach:
Najlepszym pierwszym krokiem jest NIS2 and ISO 27001 Integration Workshop. W krótkim warsztacie można ustalić, które wymagania już są pokryte, gdzie są luki, jakie dowody istnieją i jak zbudować jeden plan bez dublowania pracy.
Nie automatycznie. ISO 27001 bardzo pomaga, ale trzeba osobno sprawdzić podleganie NIS2, krajowe przepisy, zakres, zgłaszanie incydentów, dostawców i dowody.
Tak, jeśli firma chce uporządkować zarządzanie bezpieczeństwem informacji w sposób powtarzalny i audytowalny. ISO 27001 może być bardzo dobrym szkieletem dla NIS2.
Najpierw połącz zakres, rejestr ryzyk, Deklarację Stosowania i macierz dowodów. To szybko pokaże, co jest już pokryte, a gdzie są luki.
Nie zawsze. Często wystarczy rozszerzyć istniejące procedury ISO 27001 o wymagania NIS2, zwłaszcza dotyczące zgłaszania incydentów, dostawców i nadzoru zarządu.
Analiza podlegania, rejestr ryzyk, Deklaracja Stosowania, raport MFA, access review, test odtworzenia, raport tabletop, ocena dostawców, szkolenia i przegląd zarządzania.
Czasem pomoże, ale klient może nadal pytać o konkretne wymagania NIS2: incydenty, 24 i 72 godziny, dostawców, ciągłość działania, dowody i podleganie.
Najlepiej właściciel programu po stronie bezpieczeństwa lub compliance, z udziałem zarządu, IT, legal, risk, DPO, HR, zakupów i właścicieli procesów biznesowych.
Zacznij od jednej tabeli: wymaganie NIS2, element ISO 27001, kontrola, właściciel, dowód, status i luka. To najprostszy sposób, aby przestać zarządzać dwoma projektami osobno.
NIS2 i ISO 27001 nie muszą konkurować ze sobą ani tworzyć dwóch oddzielnych strumieni pracy. NIS2 wskazuje obowiązki regulacyjne, a ISO 27001 daje system zarządzania, który pomaga te obowiązki wdrożyć, nadzorować i udowodnić.
Najlepszy praktyczny plan łączy analizę podlegania, zakres systemu zarządzania, rejestr ryzyk, Deklarację Stosowania, kontrole ISO 27002, procedury, testy, dostawców, szkolenia, audyty i dowody w jednym modelu.
Najlepsza zasada brzmi: jeden rejestr ryzyk, jedna roadmapa, jedna macierz kontroli i jedno repozytorium dowodów. Wtedy NIS2 nie jest dodatkową warstwą chaosu, tylko naturalnym rozszerzeniem dojrzałego systemu zarządzania bezpieczeństwem informacji.
Lista kontrolna NIS2 dla firm: 20 działań przed audytem lub kontrolą
Lista kontrolna NIS2 przed audytem lub kontrolą powinna obejmować nie tylko polityki, ale przede wszystkim dowody działania. Firma powinna potwierdzić podleganie, zakres usług, właścicieli ryzyk, rejestr aktywów, środki zarządzania ryzykiem, MFA, backup, test odtworzenia, incident response, zgłaszanie incydentów, dostawców, szkolenia zarządu i pracowników, logi, podatności, przeglądy dostępów oraz pakiet dowodów. Audytor lub organ będzie pytał nie tylko „czy macie procedurę?”, ale „kiedy ostatnio ją testowaliście i jaki macie dowód?”.
Opracowanie: Zespół redakcyjny CCyber
Przed audytem lub kontrolą NIS2 firma powinna przygotować nie tylko dokumenty, ale też dowody, że cyberbezpieczeństwo działa w praktyce. Najważniejsze 20 działań to: potwierdzenie podlegania, określenie zakresu usług i systemów, wyznaczenie właścicieli, przygotowanie rejestru ryzyk, wykonanie analizy luk, zatwierdzenie planu działań przez zarząd, uporządkowanie polityk, inwentaryzacja aktywów, MFA i kontrola dostępu, przegląd uprawnień, backup i test odtworzenia, plan reagowania na incydenty, procedura zgłaszania 24 i 72 godziny, ćwiczenie tabletop, logi i monitoring, zarządzanie podatnościami, bezpieczeństwo dostawców, szkolenia, repozytorium dowodów oraz próbny audyt wewnętrzny. Audyt lub kontrola zwykle nie kończy się na pytaniu „czy macie dokument?”. Kluczowe pytanie brzmi: „czy potraficie pokazać, że dokument jest stosowany?”.
Lipiec 2026
Gotowość do audytu NIS2 oznacza, że organizacja potrafi pokazać trzy rzeczy:
Audyt albo kontrola nie polega wyłącznie na sprawdzeniu, czy firma ma politykę bezpieczeństwa. W praktyce pytania będą dotyczyć tego, kto jest właścicielem ryzyka, kiedy odbył się ostatni przegląd, jakie były wyniki testów, które luki są otwarte, kto zatwierdził wyjątki i jak firma reaguje na incydenty.
Zakres audytu zależy od roli firmy, sektora, przepisów krajowych, oczekiwań klienta i celu kontroli. W praktyce warto przygotować się na pytania o:
Każdy obszar przygotowania powinien mieć dwie warstwy: dokument i dowód. Dokument mówi, co firma deklaruje. Dowód pokazuje, że deklaracja działa w praktyce.
Pierwszym działaniem jest formalna analiza podlegania. Firma powinna wiedzieć, czy jest podmiotem kluczowym, ważnym, dostawcą dla takiego podmiotu albo organizacją pośrednio objętą wymaganiami klienta.
Dowód: analiza podlegania z datą, źródłami, wnioskiem i decyzją zarządu.
Audytor musi wiedzieć, czego dotyczy program NIS2. Bez zakresu nie da się ocenić ryzyka ani kontroli.
Dowód: mapa zakresu NIS2, lista systemów i usług krytycznych oraz uzasadnienie wyłączeń.
Brak właścicieli to jedna z najczęstszych luk. NIS2 wymaga realnego zarządzania ryzykiem, a nie anonimowych zadań w arkuszu.
Dowód: macierz odpowiedzialności RACI albo lista właścicieli z zatwierdzeniem zarządu.
Rejestr ryzyk pokazuje, że firma zarządza cyberbezpieczeństwem w sposób biznesowy. Powinien być powiązany z usługami krytycznymi, dostawcami i planem działań.
Dowód: aktualny rejestr ryzyk i protokół przeglądu ryzyk przez zarząd lub komitet ryzyka.
Analiza luk pokazuje, co firma ma już wdrożone, czego brakuje i które działania są priorytetem przed audytem.
Dowód: NIS2 gap analysis z oceną luk, priorytetem, właścicielem i planem naprawczym.
Audytor może zapytać, czy zarząd zna ryzyka i zatwierdził środki zarządzania ryzykiem. Sam plan IT nie wystarczy.
Dowód: uchwała, notatka zarządcza albo protokół zatwierdzenia roadmapy NIS2.
Polityki powinny być aktualne, krótkie i zgodne z realnym sposobem działania firmy. Nie warto pokazywać dokumentów, których organizacja nie stosuje.
Dowód: zatwierdzone dokumenty z właścicielem, wersją, datą przeglądu i zakresem.
Nie można chronić systemów, których firma nie zna. Rejestr aktywów jest podstawą kontroli dostępu, backupu, monitoringu i reagowania na incydenty.
Dowód: rejestr aktywów z właścicielami, krytycznością, danymi i datą ostatniej aktualizacji.
Konta uprzywilejowane są jednym z najważniejszych obszarów kontroli. Brak MFA albo zbyt wielu administratorów to typowa luka przed audytem.
Dowód: raport MFA, lista kont administratorów, raport PAM lub PIM, jeśli dotyczy.
Access review pokazuje, że firma kontroluje, kto ma dostęp do systemów i danych. To bardzo ważny dowód audytowy.
Dowód: raport przeglądu uprawnień z decyzjami: zostaje, ograniczyć, odebrać, wyjaśnić.
Backup bez testu odtworzenia jest słabym dowodem. Audytor lub organ może zapytać, kiedy firma ostatnio odzyskała dane z kopii i jaki był wynik.
Dowód: raport backupu, raport testu restore i lista działań naprawczych po teście.
Plan reagowania powinien działać w pierwszych godzinach incydentu. Musi być jasny, krótki i przypisany do ról.
Dowód: incident response plan, lista kontaktów awaryjnych i właściciele ról.
NIS2 przewiduje etapowe zgłaszanie istotnych incydentów. Firma musi umieć szybko zebrać minimalne informacje i eskalować sprawę.
Dowód: procedura zgłaszania incydentów, szablony raportów i test ścieżki eskalacji.
Ćwiczenie scenariuszowe jest jednym z najlepszych dowodów gotowości. Pokazuje, czy procedury działają, czy ludzie znają role i czy zarząd umie podejmować decyzje pod presją.
Dowód: raport z ćwiczenia tabletop z wnioskami, lukami i planem działań.
Bez logów firma może nie wiedzieć, co się stało, kiedy i z jakiego konta. Logi są ważne także jako dowód po incydencie.
Dowód: lista źródeł logów, polityka retencji, raport alertów i przykłady reakcji na alerty.
Organizacja powinna pokazać, że wykrywa, ocenia i zamyka podatności. Sam raport ze skanera nie wystarczy.
Dowód: raport podatności, lista działań naprawczych, dowody retestu i decyzje o akceptacji ryzyka.
NIS2 mocno podkreśla bezpieczeństwo łańcucha dostaw. Przed audytem firma powinna znać dostawców krytycznych i ich wpływ na usługi.
Dowód: rejestr dostawców krytycznych, oceny ryzyka dostawców i wymagania bezpieczeństwa w umowach.
NIS2 podnosi odpowiedzialność zarządu, więc szkolenie kierownictwa jest ważnym elementem przygotowania. Pracownicy też powinni znać podstawowe procedury.
Dowód: plan szkoleń, lista uczestników, materiały, wynik testu wiedzy i raport skuteczności.
W audycie liczy się czas. Jeśli firma ma dowody rozproszone po skrzynkach, folderach i komunikatorach, kontrola będzie chaotyczna.
Dowód: macierz dowodów z właścicielami, datami, statusem i lokalizacją plików.
Próbny audyt pozwala znaleźć braki przed kontrolą. Powinien sprawdzić nie tylko dokumenty, ale też rozmowy z właścicielami procesów i dostępność dowodów.
Dowód: raport audytu wewnętrznego, lista niezgodności, obserwacje i plan działań korygujących.
Raport dla zarządu powinien być krótki i decyzyjny. Nie powinien być listą technicznych szczegółów. Powinien pokazać, czy firma jest gotowa, co jest ryzykiem i jakie decyzje są potrzebne.
Firma ma polityki, ale nie ma raportów, testów, logów, decyzji ani działań naprawczych.
Firma zakłada, że NIS2 jej dotyczy albo nie dotyczy, ale nie ma udokumentowanego wniosku.
Zarząd rozmawiał o cyberbezpieczeństwie, ale nie ma protokołów, budżetu, akceptacji ryzyka ani zatwierdzonej roadmapy.
Audytor pyta o odtworzenie, a firma pokazuje tylko, że kopia się wykonuje.
Plan istnieje, ale nikt nie sprawdził, czy działa w pierwszych 24 i 72 godzinach.
Dostawcy mają dostęp do danych i systemów, ale nie zostali ocenieni ani wpisani do rejestru ryzyka.
Dowody są rozproszone i nikt nie odpowiada za ich aktualność.
Niektóre braki można szybko zamknąć, ale testy, ćwiczenia, przeglądy i dowody wymagają czasu.
Firma technologiczna przygotowuje się do audytu klienta z sektora regulowanego. Ma politykę bezpieczeństwa, backup, MFA i zewnętrznego dostawcę IT. Podczas przeglądu okazuje się jednak, że nie ma formalnej analizy podlegania, rejestr ryzyk jest nieaktualny, backup nie był testowany od roku, access review nie obejmował dostawców, a plan incydentu nie był ćwiczony.
Firma nie próbuje tworzyć dużej dokumentacji od zera. Tworzy listę 20 działań przed audytem. W pierwszym miesiącu ustala zakres, właścicieli i dowody. W drugim miesiącu wykonuje access review, test restore, ocenę dostawców i szkolenia. W trzecim miesiącu robi tabletop i próbny audyt wewnętrzny.
Efekt jest praktyczny: firma nie tylko lepiej przechodzi audyt, ale też realnie poprawia gotowość na incydent. Największą zmianą nie jest nowa polityka. Największą zmianą jest to, że każdy ważny obszar ma właściciela, dowód i plan naprawczy.
ccyber.io pomaga firmom przygotować się do audytu, kontroli i wymagań NIS2 w sposób praktyczny, oparty na ryzyku i dowodach. Nie zaczynamy od dokumentów dla dokumentów. Zaczynamy od zakresu, podlegania, ryzyk, systemów krytycznych, incydentów, dostawców i odpowiedzialności zarządu.
Możemy wesprzeć organizację w obszarach:
Najlepszym pierwszym krokiem jest NIS2 Audit Readiness Workshop. W krótkim warsztacie można ustalić, które dowody już istnieją, czego brakuje, jakie ryzyka są najpilniejsze i które działania trzeba wykonać przed audytem lub kontrolą.
Nie. Polityki są potrzebne, ale audytor będzie oczekiwał dowodów działania: raportów, testów, przeglądów, logów, szkoleń, decyzji zarządu i działań naprawczych.
Najpierw przygotuj analizę podlegania, zakres, rejestr ryzyk, właścicieli, macierz dowodów i raport dla zarządu. Potem zamykaj luki techniczne i operacyjne.
Raport MFA, access review, test restore, rejestr ryzyk, incident response plan, raport tabletop, ocena dostawców, szkolenia zarządu i pracowników oraz decyzje zarządu.
Warto. To jeden z najlepszych dowodów, że firma potrafi działać po incydencie, eskalować do zarządu i przygotować zgłoszenia w krótkich terminach.
Tak, bezpieczeństwo łańcucha dostaw jest ważnym elementem NIS2. Firma powinna mieć rejestr dostawców krytycznych, ocenę ryzyka i wymagania bezpieczeństwa w umowach.
Zarząd powinien znać status podlegania, największe ryzyka, plan działań, luki krytyczne, decyzje budżetowe, status incydentów, dostawców i dowodów.
Podstawowy pakiet można uporządkować w 90 dni, jeśli firma ma właściciela działań i dostęp do dowodów. Pełna dojrzałość zwykle wymaga dłuższego programu.
Zacznij od macierzy dowodów: wymaganie, dowód, właściciel, data, status i luka. To szybko pokaże, gdzie firma jest gotowa, a gdzie brakuje realnych dowodów.
Lista kontrolna NIS2 przed audytem lub kontrolą powinna skupiać się na dowodach, a nie tylko na dokumentach. Firma musi pokazać, że zna zakres, ryzyka, systemy, dostawców, incydenty i odpowiedzialność zarządu.
Najważniejsze 20 działań to analiza podlegania, zakres, właściciele, rejestr ryzyk, gap analysis, decyzje zarządu, polityki, aktywa, MFA, access review, backup, restore test, incident response, zgłaszanie incydentów, tabletop, logi, podatności, dostawcy, szkolenia, repozytorium dowodów i próbny audyt.
Najlepsza zasada brzmi: audyt przygotowuje się przed audytem, a nie w trakcie. Im wcześniej firma zacznie zbierać dowody działania, tym mniejsze ryzyko chaosu, niezgodności i kosztownych działań awaryjnych.
Ile firm objętych NIS2 w Polsce?
Nie ma jednej pewnej, ostatecznej liczby firm objętych NIS2 w Polsce, którą można traktować jako zamkniętą i niezmienną. Liczba zależy od finalnej transpozycji do prawa krajowego, kwalifikacji sektorowej, wielkości podmiotu, wyjątków dla wybranych usług oraz rejestracji podmiotów kluczowych i ważnych. Bezpośrednio NIS2 dotyczy głównie średnich i dużych organizacji z określonych sektorów, ale pośrednio obejmie znacznie więcej firm jako dostawców, podwykonawców i partnerów podmiotów regulowanych.
Opracowanie: Zespół redakcyjny CCyber
Na pytanie „ile firm będzie objętych NIS2 w Polsce?” nie ma jednej prostej i ostatecznej odpowiedzi. Najbezpieczniejsza odpowiedź brzmi: liczba będzie zależała od finalnego brzmienia polskich przepisów wdrażających NIS2, kwalifikacji sektorowej, wielkości organizacji, wyjątków dla niektórych typów usług oraz procesu identyfikacji lub rejestracji podmiotów kluczowych i ważnych. Bezpośrednio NIS2 obejmuje przede wszystkim średnie i duże podmioty z sektorów wskazanych w dyrektywie, a w niektórych przypadkach także mniejsze organizacje niezależnie od wielkości. Pośrednio wymagania dotkną znacznie większej liczby firm, ponieważ podmioty objęte NIS2 będą wymagać bezpieczeństwa także od swoich dostawców, podwykonawców i partnerów technologicznych.
Lipiec 2026
Nie ma jednej pewnej liczby firm objętych NIS2 w Polsce z kilku powodów.
NIS2 jest dyrektywą Unii Europejskiej. Oznacza to, że państwa członkowskie muszą wdrożyć ją do prawa krajowego. Dopiero krajowe przepisy określają szczegóły: właściwe organy, tryb rejestracji, obowiązki proceduralne, sankcje i praktyczne zasady kwalifikacji.
Firma może być średnia albo duża, ale jeśli nie działa w sektorze objętym NIS2, sama wielkość nie przesądza jeszcze o podleganiu. Trzeba sprawdzić sektor, podsektor i typ usługi.
Co do zasady NIS2 stosuje się do podmiotów średnich i dużych w sektorach objętych dyrektywą. Są jednak wyjątki, w których mniejsze organizacje też mogą podlegać regulacji, na przykład ze względu na rodzaj usługi, znaczenie dla społeczeństwa, gospodarki albo bezpieczeństwa publicznego.
Dyrektywa przewiduje listy podmiotów kluczowych i ważnych oraz notyfikowanie Komisji Europejskiej liczby takich podmiotów według sektorów i podsektorów. To oznacza, że liczba jest nie tylko kwestią teoretycznego oszacowania, ale także procesu administracyjnego.
Nawet jeśli firma nie jest bezpośrednio podmiotem kluczowym albo ważnym, może być dostawcą takiego podmiotu. Wtedy wymagania NIS2 mogą pojawić się w umowach, ankietach bezpieczeństwa, audytach klientów, wymaganiach dostępu, SLA, raportowaniu incydentów i oczekiwaniach dotyczących backupu, MFA oraz ciągłości działania.
NIS2 obejmuje podmioty publiczne i prywatne z typów wskazanych w załącznikach I i II dyrektywy. Co do zasady chodzi o podmioty, które kwalifikują się jako średnie przedsiębiorstwa albo przekraczają progi dla średnich przedsiębiorstw i świadczą usługi lub prowadzą działalność w Unii Europejskiej.
NIS2 obejmuje sektory o wysokiej krytyczności oraz pozostałe sektory krytyczne. Dla polskich firm ważne jest to, że zakres jest szerszy niż w poprzednim NIS1.
Co do zasady NIS2 jest skierowana głównie do podmiotów średnich i dużych w określonych sektorach. To nie oznacza jednak, że małe firmy mogą automatycznie zignorować temat.
To rozróżnienie jest bardzo ważne, bo wiele nieporozumień wokół liczby firm objętych NIS2 wynika z mieszania tych dwóch grup.
To podmioty, które spełniają kryteria wynikające z NIS2 i krajowej ustawy wdrażającej. Mogą być podmiotami kluczowymi albo ważnymi i mają własne obowiązki regulacyjne.
To firmy, które formalnie mogą nie być podmiotami kluczowymi albo ważnymi, ale obsługują podmioty regulowane. W praktyce muszą spełnić część wymagań, bo oczekuje tego klient.
Firma pośrednio dotknięta NIS2 może nie mieć obowiązku zgłoszenia się do rejestru jako podmiot regulowany, ale może otrzymać od klienta wymagania dotyczące MFA, backupu, ciągłości działania, zgłaszania incydentów, testów bezpieczeństwa, ISO 27001, dowodów kontroli albo prawa do audytu.
Najlepszym podejściem jest krótka analiza podlegania. Nie powinna być oparta na samym kodzie PKD. PKD może pomóc, ale zwykle nie wystarczy, bo liczy się rzeczywista usługa, sektor, skala i rola firmy w łańcuchu dostaw.
Odpowiedz na pytanie, czy firma działa w jednym z sektorów NIS2 albo obsługuje klientów z tych sektorów.
Oceń, czy firma jest średnim albo dużym przedsiębiorstwem w rozumieniu kryteriów stosowanych przez dyrektywę. Trzeba brać pod uwagę nie tylko liczbę pracowników, ale także powiązania kapitałowe, obrót i sumę bilansową.
Niektóre typy usług mogą być objęte niezależnie od wielkości. To szczególnie ważne przy usługach cyfrowych, zaufania, DNS, domenach, komunikacji elektronicznej i usługach o szczególnym znaczeniu.
Jeżeli firma świadczy usługi dla podmiotu regulowanego, może zostać objęta wymaganiami kontraktowymi. To często najważniejszy scenariusz dla MŚP.
Finalna odpowiedź dla Polski musi wynikać z aktualnych przepisów wdrażających NIS2, czyli z nowelizacji KSC i powiązanych aktów. Dlatego każda analiza powinna mieć datę i wskazanie wersji przepisów, na której została oparta.
Dowód do przygotowania: analiza podlegania NIS2 z datą, źródłami, wersją przepisów i decyzją zarządu.
Szacunki liczby firm objętych NIS2 mogą się różnić, ponieważ różni autorzy liczą co innego.
To podejście obejmuje podmioty kluczowe i ważne, które spełniają kryteria sektorowe i wielkościowe lub wyjątki.
To podejście pokazuje realny wpływ NIS2 na gospodarkę, ale nie oznacza, że każdy dostawca staje się automatycznie podmiotem regulowanym.
To może zawyżać wynik, jeśli nie uwzględnia wielkości, rodzaju usługi i wyjątków.
PKD jest pomocne, ale nie zawsze oddaje rzeczywisty charakter usługi. Firma może mieć PKD technologiczne, ale świadczyć usługę poza zakresem NIS2, albo odwrotnie.
Jeżeli firma jest średnia albo duża i działa w sektorze wskazanym w NIS2, analiza podlegania powinna być priorytetem.
Dostawcy IT, managed service providers, managed security service providers, integratorzy, firmy chmurowe, hostingowe i backupowe powinni sprawdzić zarówno własne podleganie, jak i wymagania klientów.
Firmy tworzące lub utrzymujące systemy dla sektorów regulowanych mogą szybko dostać wymagania NIS2 w umowach i audytach.
Jeżeli dostawca ma konto administratora, VPN, dostęp do kodu, środowiska produkcyjnego, backupu, danych klienta albo monitoringu, będzie traktowany jako ryzyko łańcucha dostaw.
Produkcja wyrobów medycznych, komputerów, elektroniki, urządzeń elektrycznych, maszyn, pojazdów i wybranych produktów może znaleźć się w zakresie załącznika II.
Brak pewności nie jest problemem, jeśli firma działa. Problemem jest brak decyzji. Zarząd powinien zlecić formalną analizę podlegania i przygotować minimalny plan działań niezależnie od tego, czy firma ostatecznie znajdzie się bezpośrednio w zakresie.
Liczba firm objętych NIS2 jest mniej ważna niż to, czy konkretna organizacja wykonała własną analizę podlegania.
PKD może pomóc, ale nie zastępuje analizy rzeczywistej usługi, sektora, wielkości, klientów i wyjątków.
Firma może nie być bezpośrednio regulowana, ale może dostać wymagania NIS2 od klientów.
Nawet jeśli firma czeka na finalne przepisy krajowe, może już teraz wdrożyć podstawy: MFA, backup, incident response, access review, dostawcy i szkolenia.
Jeśli firma uzna, że NIS2 jej nie dotyczy, powinna mieć na to udokumentowaną podstawę. Ustna opinia nie wystarczy.
Brak bezpośredniego podlegania nie oznacza, że klient nie może wymagać podobnych kontroli w umowie.
To właśnie sprzedaż, zakupy i legal często jako pierwsze widzą wymagania NIS2 w umowach, ankietach i zapytaniach ofertowych.
Firma SaaS zatrudnia 70 osób i świadczy usługę dla klientów z sektora zdrowia, produkcji i administracji. Zarząd pyta: „czy jesteśmy jedną z firm objętych NIS2 w Polsce?”. Pierwsza odpowiedź brzmi: nie da się odpowiedzieć po samej liczbie pracowników ani po ogólnym haśle „SaaS”. Trzeba sprawdzić sektor, typ usługi, klientów, dane, dostęp do systemów klientów i finalne przepisy krajowe.
Analiza pokazuje, że firma może nie być oczywistym podmiotem kluczowym, ale jest ważnym dostawcą dla klientów regulowanych. W umowach pojawiają się wymagania dotyczące zgłaszania incydentów, MFA, backupu, testów bezpieczeństwa, dostępu dostawców, podwykonawców i dowodów kontroli.
Firma przygotowuje pakiet NIS2 readiness. Wdraża rejestr ryzyk, przegląd uprawnień, test restore, procedurę incident response, ocenę dostawców i szkolenie zarządu. Nawet jeśli finalna kwalifikacja prawna będzie wymagała doprecyzowania, firma jest gotowa na wymagania klientów i audyty.
ccyber.io pomaga firmom ustalić, czy NIS2 może ich dotyczyć bezpośrednio albo pośrednio. Nie opieramy się na jednej rynkowej liczbie. Analizujemy sektor, usługi, wielkość, klientów, łańcuch dostaw, umowy, dane, systemy krytyczne i wymagania krajowe.
Możemy wesprzeć organizację w obszarach:
Najlepszym pierwszym krokiem jest NIS2 Applicability Workshop. W krótkim warsztacie można ustalić, czy firma może być bezpośrednio objęta regulacją, czy jest pośrednio dotknięta wymaganiami klientów i jakie działania warto rozpocząć bez czekania na pełną pewność.
Nie ma jednej pewnej, ostatecznej liczby, którą można bezpiecznie stosować dla wszystkich decyzji. Liczba będzie zależała od krajowej transpozycji, sektorów, wielkości firm, wyjątków i procesu identyfikacji podmiotów kluczowych oraz ważnych.
Nie. Średnia firma podlega NIS2 wtedy, gdy działa w sektorze objętym dyrektywą albo spełnia szczególne kryteria wynikające z dyrektywy lub prawa krajowego.
Nie zawsze. Co do zasady NIS2 koncentruje się na średnich i dużych podmiotach, ale przewiduje wyjątki. Małe firmy mogą też być pośrednio objęte przez wymagania klientów.
Tak, szczególnie jeśli świadczy usługi zarządzane, bezpieczeństwa, chmury, hostingu, infrastruktury cyfrowej albo obsługuje klientów regulowanych.
Nie. PKD jest tylko punktem startu. Trzeba sprawdzić rzeczywisty rodzaj usługi, sektor, klientów, wielkość, rolę w łańcuchu dostaw i przepisy krajowe.
Wykonaj analizę podlegania, przygotuj wniosek dla zarządu i rozpocznij podstawowe działania bezpieczeństwa: MFA, backup, incident response, access review, dostawcy i szkolenia.
Tak. Klient regulowany może wymagać od dostawcy określonych zabezpieczeń, raportowania incydentów, dowodów kontroli, audytów i zapisów umownych.
Zacznij od trzech rzeczy: analiza podlegania, lista klientów regulowanych i gap analysis podstawowych kontroli cyberbezpieczeństwa.
Pytanie „ile firm objętych NIS2 w Polsce?” jest ważne, ale może prowadzić do złego wniosku, jeśli firma szuka tylko jednej liczby. Odpowiedź zależy od finalnej transpozycji, sektorów, wielkości, wyjątków, list podmiotów i praktyki organów.
Bezpośrednio NIS2 obejmie przede wszystkim średnie i duże podmioty z określonych sektorów oraz wybrane organizacje niezależnie od wielkości. Pośrednio wymagania obejmą znacznie większą grupę firm, zwłaszcza dostawców IT, software house’y, firmy SaaS, integratorów, dostawców chmury, backupu i usług zarządzanych.
Najlepsza zasada brzmi: nie opieraj się na cudzym szacunku. Wykonaj własną analizę podlegania, udokumentuj decyzję i przygotuj minimum kontroli, które będzie potrzebne niezależnie od formalnej kwalifikacji.
Dyrektywa NIS2: Za co osobiście odpowiada zarząd firmy?
NIS2 nie oznacza, że zarząd musi samodzielnie konfigurować firewalle, backupy czy systemy monitoringu. Oznacza jednak, że zarząd ma zatwierdzać środki zarządzania ryzykiem cyber, nadzorować ich wdrożenie, rozumieć wpływ ryzyk na działalność firmy, zapewnić zasoby, przejść szkolenie i posiadać dowody, że cyberbezpieczeństwo jest realnie zarządzane. Osobista odpowiedzialność zarządu dotyczy przede wszystkim braku nadzoru, braku decyzji, ignorowania ryzyka, braku reakcji na zalecenia i niezdolności wykazania, że firma działała odpowiedzialnie.
Opracowanie: Zespół redakcyjny CCyber
Zarząd firmy odpowiada pod NIS2 przede wszystkim za nadzór nad cyberbezpieczeństwem jako ryzykiem biznesowym. Nie musi samodzielnie wdrażać technicznych zabezpieczeń, ale musi zatwierdzić środki zarządzania ryzykiem cyber, nadzorować ich wdrożenie, zapewnić zasoby, rozumieć ryzyka, uczestniczyć w szkoleniach i wymagać dowodów działania kontroli. Osobista odpowiedzialność zarządu nie oznacza automatycznej winy za każdy incydent. Oznacza jednak, że zarząd nie może powiedzieć „to sprawa IT”, jeśli firma nie miała analizy ryzyka, planu reagowania, backupu, kontroli dostępu, nadzoru nad dostawcami, szkoleń, raportowania i dowodów. Szczegółowy zakres odpowiedzialności zależy od prawa krajowego, roli konkretnej osoby, struktury firmy i okoliczności naruszenia.
Lipiec 2026
Osobista odpowiedzialność zarządu pod NIS2 nie oznacza, że każdy członek zarządu staje się administratorem systemów albo specjalistą od cyberbezpieczeństwa. Oznacza, że cyberbezpieczeństwo staje się obszarem, nad którym zarząd musi sprawować realny nadzór.
W praktyce zarząd odpowiada za to, czy firma:
Najprościej: zarząd nie odpowiada za każdy techniczny detal, ale odpowiada za to, czy w firmie istnieje skuteczny system zarządzania ryzykiem cyber.
Zarząd może delegować wykonanie zadań do IT, security, compliance, zewnętrznych doradców i dostawców. Nie powinien jednak delegować odpowiedzialności za nadzór.
Jeśli zarząd nie ma raportów, nie zna ryzyk i nie podejmuje decyzji, trudno będzie wykazać, że nadzór był realny.
Pierwszą odpowiedzialnością zarządu jest dopilnowanie, aby firma wiedziała, czy podlega NIS2 albo krajowym przepisom wdrażającym. Nie powinno to być założenie ani opinia ustna. Potrzebna jest udokumentowana analiza.
Analiza powinna obejmować:
Dowód dla zarządu: analiza podlegania NIS2 z decyzją, kto jest właścicielem dalszych działań.
NIS2 wskazuje, że organy zarządzające mają zatwierdzać środki zarządzania ryzykiem cyber. To oznacza, że zarząd powinien znać główne ryzyka i zaakceptować plan środków technicznych, operacyjnych i organizacyjnych.
Środki zarządzania ryzykiem obejmują między innymi:
Dowód dla zarządu: zatwierdzony plan środków zarządzania ryzykiem, powiązany z rejestrem ryzyk i budżetem.
Zatwierdzenie planu nie wystarczy. Zarząd powinien nadzorować, czy plan jest wykonywany. Nadzór nie musi oznaczać codziennego monitorowania zadań. Powinien jednak oznaczać cykliczne raportowanie, pytania o opóźnienia i decyzje w sprawie ryzyk wysokiego priorytetu.
Zarząd powinien widzieć:
Dowód dla zarządu: cykliczny panel raportowy NIS2 z decyzjami i działaniami naprawczymi.
NIS2 wymaga, aby członkowie organów zarządzających odbywali szkolenia. Celem nie jest zrobienie z zarządu zespołu technicznego. Celem jest to, aby zarząd potrafił rozumieć ryzyka cyber, oceniać praktyki zarządzania ryzykiem i rozumieć wpływ cyberbezpieczeństwa na usługi firmy.
Szkolenie zarządu powinno obejmować:
Dowód dla zarządu: materiały szkoleniowe, lista uczestników, wynik testu albo potwierdzenie udziału i notatka z wnioskami.
Zarząd nie musi sam wdrażać kontroli, ale musi zapewnić realne zasoby. Brak budżetu nie usuwa ryzyka. Może natomiast pokazać, że firma świadomie nie wdrożyła potrzebnych środków.
Zarząd powinien wymagać jasnej informacji:
Dowód dla zarządu: zatwierdzony budżet albo świadoma decyzja o akceptacji ryzyka z uzasadnieniem i terminem przeglądu.
NIS2 przewiduje krótkie terminy zgłaszania istotnych incydentów. Zarząd powinien upewnić się, że organizacja ma proces, który działa w pierwszych godzinach incydentu.
Firma powinna umieć przygotować:
Zarząd nie musi sam pisać zgłoszenia, ale powinien wiedzieć, kto decyduje o kwalifikacji incydentu, kto informuje organ, kto prowadzi komunikację i kto zatwierdza raport.
Dowód dla zarządu: procedura zgłaszania incydentów, szablony zgłoszeń i raport z ćwiczenia pierwszych 24 i 72 godzin.
Cyberbezpieczeństwo w NIS2 dotyczy nie tylko ochrony przed atakiem, ale też ograniczenia wpływu incydentu na usługi. Zarząd powinien wiedzieć, czy firma potrafi kontynuować działanie i odtworzyć systemy krytyczne.
Zarząd powinien pytać:
Dowód dla zarządu: plan ciągłości działania, raport testu odtwarzania i decyzje dotyczące ryzyk pozostających po teście.
NIS2 podkreśla bezpieczeństwo łańcucha dostaw. Zarząd powinien wiedzieć, którzy dostawcy są krytyczni i jakie ryzyka wnoszą do organizacji.
Program dostawców powinien obejmować:
Dowód dla zarządu: rejestr dostawców krytycznych, oceny ryzyka i decyzje dotyczące dostawców wysokiego ryzyka.
Zarząd odpowiada za ton organizacji. Jeśli pracownicy boją się zgłaszać błędy albo podejrzane sytuacje, firma traci czas. Jeśli managerowie wymagają obchodzenia procedur, szkolenia nie zadziałają.
Zarząd powinien wspierać:
Dowód dla zarządu: plan szkoleń, raport skuteczności szkoleń, raport zgłoszeń i działania naprawcze po ćwiczeniach.
W kontroli, audycie albo po incydencie sama deklaracja nie wystarczy. Firma musi umieć pokazać dowody. Zarząd powinien wymagać uporządkowanego pakietu dowodów.
Dowody powinny obejmować:
Dowód dla zarządu: repozytorium dowodów i macierz wymagań NIS2, KSC, ISO 27001 oraz wymagań klientów.
Nie każdy incydent oznacza automatyczną odpowiedzialność zarządu. Incydenty mogą się zdarzyć nawet w dobrze zarządzanych organizacjach. Kluczowe pytanie brzmi: czy firma działała odpowiedzialnie przed incydentem, w trakcie incydentu i po incydencie.
Wiele firm omawia cyberbezpieczeństwo na spotkaniach, ale nie dokumentuje decyzji. To błąd. Po incydencie liczy się ślad decyzyjny.
IT jest kluczowe, ale NIS2 dotyczy zarządzania ryzykiem, ciągłości działania, dostawców, budżetu, incydentów i odpowiedzialności zarządczej.
Firma zakłada, że NIS2 jej nie dotyczy, bo nie jest klasyczną infrastrukturą krytyczną. Zakres NIS2 jest szerszy, a dodatkowo wymagania mogą pojawić się przez klientów i łańcuch dostaw.
Ryzyka są omawiane, ale nie ma decyzji, właścicieli, budżetu i terminów. Po incydencie trudno pokazać realny nadzór.
Zarząd nie musi być techniczny, ale musi rozumieć ryzyka, obowiązki i konsekwencje decyzji.
Plan reagowania, backup i ciągłość działania bez testów są tylko założeniem. Zarząd powinien wymagać raportów z ćwiczeń.
Dostawca ICT, chmura, oprogramowanie, integrator albo firma serwisowa może być źródłem incydentu. NIS2 wymaga uwzględnienia ryzyka łańcucha dostaw.
Kary są ważne, ale większym problemem może być przerwanie usług, utrata klientów, kontrola po incydencie i brak możliwości wykazania, że firma działała odpowiedzialnie.
Firma może robić wiele dobrych rzeczy, ale bez dowodów trudno to pokazać organowi, klientowi, audytorowi albo ubezpieczycielowi.
Firma technologiczna świadczy usługi dla klientów z sektora zdrowia i przemysłu. Zarząd początkowo zakłada, że NIS2 to temat techniczny, więc przekazuje go do IT. Po pierwszej analizie okazuje się, że firma jest ważnym dostawcą dla podmiotów regulowanych, ma dostęp do danych klientów i utrzymuje systemy wpływające na ciągłość usług klientów.
Analiza luk pokazuje, że firma ma MFA, backup i monitoring, ale brakuje formalnego rejestru ryzyk, decyzji zarządu, ćwiczenia incydentowego, programu dostawców, raportów z access review i dowodów szkoleń. IT wykonywało wiele działań, ale zarząd nie otrzymywał cyklicznego raportu i nie podejmował formalnych decyzji o ryzyku.
Zarząd uruchamia 90-dniowy plan. Powstaje analiza podlegania, rejestr ryzyk, plan działań, raport dla zarządu, ćwiczenie scenariuszowe, test odtwarzania i rejestr dostawców krytycznych. Najważniejsza zmiana nie polega na stworzeniu jednego dokumentu. Polega na tym, że zarząd zaczyna regularnie nadzorować ryzyko cyber i podejmować udokumentowane decyzje.
ccyber.io pomaga zarządom i zespołom bezpieczeństwa przygotować organizację do NIS2 w sposób praktyczny, mierzalny i oparty na dowodach. Nie zaczynamy od dokumentów dla dokumentów. Zaczynamy od podlegania, ryzyka, odpowiedzialności zarządu, incydentów, dostawców i decyzji biznesowych.
Możemy wesprzeć organizację w obszarach:
Najlepszym pierwszym krokiem jest NIS2 Board Accountability Workshop. W krótkim warsztacie można ustalić, czy firma podlega NIS2, jakie są obowiązki zarządu, które ryzyka wymagają decyzji, jakie dowody trzeba przygotować i które działania warto rozpocząć w pierwszych 30 dniach.
NIS2 wymaga, aby organy zarządzające zatwierdzały środki zarządzania ryzykiem cyber, nadzorowały ich wdrożenie i mogły ponosić odpowiedzialność za naruszenia. Szczegółowy zakres odpowiedzialności zależy od prawa krajowego i okoliczności sprawy.
Nie automatycznie. Incydent może się wydarzyć mimo rozsądnych zabezpieczeń. Kluczowe jest, czy firma miała adekwatne środki, nadzór, procedury, zgłoszenie w terminie, reakcję i dowody.
Nie musi znać wszystkich szczegółów technicznych. Musi jednak rozumieć ryzyka, wpływ na działalność, obowiązki raportowania, stan kontroli, luki i decyzje budżetowe.
Tak. Dyrektywa wymaga szkoleń dla członków organów zarządzających, aby mieli wiedzę i umiejętności potrzebne do identyfikowania ryzyk oraz oceny praktyk zarządzania ryzykiem cyber.
Możliwe konsekwencje zależą od prawa krajowego. NIS2 przewiduje odpowiedzialność osób mających wpływ na zapewnienie zgodności oraz w określonych przypadkach możliwość czasowego zakazu pełnienia funkcji zarządczych w podmiotach kluczowych.
Nie. CISO lub vCISO może prowadzić program, ale zarząd nadal powinien zatwierdzać środki, nadzorować wdrożenie, zapewniać zasoby i podejmować decyzje o ryzyku.
Analiza podlegania, rejestr ryzyk, raporty dla zarządu, decyzje budżetowe, dowody szkoleń, testy backupu, ćwiczenia incydentowe, access review, oceny dostawców i działania naprawcze.
Zacznij od analizy podlegania, szkolenia zarządu, rejestru ryzyk, raportu stanu kontroli i planu działań na 90 dni. Potem przeprowadź ćwiczenie incydentowe i przygotuj pakiet dowodów.
Dyrektywa NIS2 nie wymaga, aby zarząd stał się działem IT. Wymaga jednak, aby zarząd realnie nadzorował cyberbezpieczeństwo jako ryzyko biznesowe. To oznacza zatwierdzanie środków zarządzania ryzykiem, nadzór nad wdrożeniem, szkolenia, decyzje budżetowe, zarządzanie dostawcami, gotowość do zgłaszania incydentów i dowody działania kontroli.
Osobista odpowiedzialność zarządu najczęściej nie będzie wynikała z samego faktu, że wystąpił incydent. Będzie wynikała z pytania, czy zarząd zrobił to, czego można racjonalnie oczekiwać: znał ryzyka, wymagał działań, zapewnił zasoby, reagował na luki, szkolił się, ćwiczył incydenty i dokumentował decyzje.
Najlepsza zasada brzmi: zarząd nie musi robić wszystkiego sam, ale musi mieć dowód, że nadzoruje. W NIS2 brak nadzoru, brak decyzji i brak dowodów są często większym problemem niż sama luka techniczna.
Jakie dowody zgodności przygotować pod NIS2, KSC i ISO 27001?
Dowody zgodności pod NIS2, KSC i ISO 27001 to nie tylko polityki i procedury. Firma powinna umieć pokazać, że cyberbezpieczeństwo działa w praktyce: ma rejestr ryzyk, właścicieli kontroli, decyzje zarządu, raporty z backupu, testy odtwarzania, access review, szkolenia, ocenę dostawców, logi, raporty podatności, ćwiczenia incident response, działania naprawcze i cykliczne przeglądy. Najlepszy pakiet dowodów pokazuje nie tylko „mamy dokument”, ale „wdrożyliśmy, testujemy, mierzymy i poprawiamy”.
Opracowanie: Zespół redakcyjny CCyber
Pod NIS2, KSC i ISO 27001 trzeba przygotować dowody, które pokazują, że firma realnie zarządza cyberbezpieczeństwem, a nie tylko posiada dokumenty. Najważniejsze dowody to: analiza podlegania, rejestr ryzyk, decyzje zarządu, polityki bezpieczeństwa, Statement of Applicability dla ISO 27001, plan postępowania z ryzykiem, raporty z backupu, testy odtwarzania, access review, MFA, zarządzanie podatnościami, szkolenia, ocena dostawców, plan reagowania na incydenty, raporty z ćwiczeń, logi, metryki i działania korygujące. Dobry pakiet dowodów odpowiada na cztery pytania: co firma miała zrobić, kto za to odpowiada, czy zostało to wykonane i jaki jest dowód, że działa.
Lipiec 2026
Dowody zgodności to dokumenty, raporty, logi, zapisy, decyzje, wyniki testów i inne ślady działania, które pokazują, że organizacja spełnia określone wymaganie. W cyberbezpieczeństwie dowody są szczególnie ważne, ponieważ wiele kontroli nie jest widocznych z zewnątrz. Trzeba pokazać, że działają w praktyce.
Przykład: polityka backupu jest dokumentem. Raport z ostatniego backupu, raport testu odtworzenia i lista problemów po teście są dowodami działania procesu.
Dobry dowód powinien pokazywać:
NIS2 jest dyrektywą UE. Wymaga zarządzania ryzykiem cyber, odpowiednich środków technicznych, operacyjnych i organizacyjnych, zgłaszania istotnych incydentów, odpowiedzialności organów zarządzających, ciągłości działania, zarządzania dostawcami i szkoleń. Dowody pod NIS2 powinny pokazywać, że firma wie, czy podlega regulacji, jakie ma ryzyka, jakie środki wdrożyła i jak reaguje na incydenty.
KSC, czyli ustawa o krajowym systemie cyberbezpieczeństwa, jest polską podstawą prawną dla krajowego systemu cyberbezpieczeństwa. Aktualny tekst należy zawsze sprawdzać w oficjalnych źródłach, ponieważ przepisy i akty wykonawcze mogą się zmieniać. Dowody pod KSC powinny być zgodne z krajowymi obowiązkami, terminami, definicjami incydentów, wymogami nadzoru i oczekiwaniami organów właściwych.
ISO 27001 jest normą systemu zarządzania bezpieczeństwem informacji. Tu dowody pokazują, że organizacja ma ISMS, czyli system zarządzania bezpieczeństwem informacji, działa według cyklu ciągłego doskonalenia i potrafi wykazać ryzyka, cele, kontrole, audyty, przeglądy zarządzania i działania korygujące.
Wspólny mianownik jest prosty: zarządzanie ryzykiem, odpowiedzialność, kontrole, testy, monitorowanie, incydenty, dostawcy, szkolenia i doskonalenie. Różni się język wymagań, ale duża część dowodów może obsługiwać jednocześnie NIS2, KSC i ISO 27001.
Nie trzeba tworzyć osobnego zestawu dokumentów dla każdej regulacji. Dobrze zaprojektowany dowód może wspierać kilka wymagań naraz.
Przykłady:
Najlepsze podejście to zbudować jedną macierz dowodów i przypisać każdy dowód do wymagań NIS2, KSC, ISO 27001, umów klientów i cyberubezpieczenia.
Macierz dowodów to centralna tabela, która mówi, jakie dowody firma posiada, czego dotyczą i kiedy trzeba je odświeżyć.
Obszar: backup i odtwarzanie.
Dowód: raport testu odtworzenia systemu krytycznego.
Właściciel: IT operations.
Częstotliwość: kwartalnie dla systemów krytycznych.
Wspiera: NIS2 continuity, KSC system zarządzania bezpieczeństwem informacji, ISO 27001 Annex A continuity and backup controls.
To pierwsza grupa dowodów. Zanim firma pokaże kontrole, musi wiedzieć, czy i w jakim zakresie podlega NIS2 oraz KSC, a dla ISO 27001 musi określić zakres ISMS.
Firma przygotowuje polityki i procedury, ale nie potrafi powiedzieć, których usług, systemów i podmiotów w grupie one dotyczą.
NIS2 i KSC przenoszą cyberbezpieczeństwo na poziom odpowiedzialności kierownictwa. ISO 27001 również wymaga zaangażowania najwyższego kierownictwa w system zarządzania bezpieczeństwem informacji.
Dobrym dowodem nie jest sama prezentacja dla zarządu. Dobrym dowodem jest protokół lub notatka z decyzjami, ryzykami, budżetem, właścicielami i terminami.
Ryzyko jest wspólnym fundamentem NIS2, KSC i ISO 27001. Bez rejestru ryzyk trudno pokazać, dlaczego wybrane kontrole są adekwatne.
Rejestr ryzyk istnieje, ale nie ma właścicieli, dat, działań, metryk ani decyzji zarządu. Wtedy jest dokumentem, a nie narzędziem zarządzania.
Polityki pokazują oczekiwany sposób działania. Procedury pokazują, jak firma wykonuje konkretne procesy. Same polityki nie wystarczą, ale są potrzebną warstwą systemu.
Polityka powinna mieć właściciela, wersję, datę zatwierdzenia, zakres, okres przeglądu i powiązanie z ryzykami oraz kontrolami.
Statement of Applicability, czyli SoA, jest jednym z najważniejszych dokumentów ISO 27001. Pokazuje, które kontrole z Annex A mają zastosowanie, które nie mają zastosowania i dlaczego.
SoA jest traktowany jak tabela do certyfikacji, a nie jako żywa mapa kontroli. Dobry SoA powinien być aktualny po zmianach ryzyka, technologii i zakresu ISMS.
Kontrola dostępu jest jednym z najważniejszych obszarów dowodowych. Przejęcie konta, zbyt szerokie uprawnienia i brak MFA to częste źródła incydentów.
Raport access review powinien pokazać nie tylko listę użytkowników, ale decyzje właścicieli: zostaje, ograniczyć, odebrać, do wyjaśnienia.
NIS2 i KSC wyraźnie podkreślają ciągłość działania, backup i odtwarzanie. ISO 27001 również wymaga przygotowania organizacji na zakłócenia i utratę dostępności.
Firma pokazuje, że backup się wykonuje, ale nie pokazuje testu odtworzenia. Dla audytu i realnej odporności restore jest ważniejszy niż sama informacja, że kopia istnieje.
Pod NIS2 i KSC dowody incident response mają szczególne znaczenie, ponieważ terminy zgłaszania są krótkie, a organ nadzoru może pytać o przebieg obsługi incydentu.
Najlepszym dowodem jest raport z ćwiczenia, w którym firma przetestowała pierwsze 24 i 72 godziny incydentu: kto decyduje, kto zgłasza, kto zbiera fakty i kto informuje zarząd.
Zarządzanie podatnościami pokazuje, że firma aktywnie wykrywa i zamyka luki, a nie czeka na incydent.
Firma ma raport z testu, ale nie ma dowodu, że podatności zostały naprawione albo świadomie zaakceptowane przez właściciela ryzyka.
NIS2 i KSC mocno podkreślają ryzyko łańcucha dostaw. ISO 27001 również wymaga zarządzania bezpieczeństwem relacji z dostawcami.
Dobrym dowodem jest karta dostawcy krytycznego: usługa, właściciel biznesowy, zakres dostępu, ryzyko, wymagania umowne, data ostatniej oceny i plan awaryjny.
Szkolenie jest wymaganiem organizacyjnym, ale także dowodem kultury bezpieczeństwa. Pod NIS2 i KSC ważne są szkolenia zarządu oraz personelu. Pod ISO 27001 ważna jest świadomość, kompetencje i zapisy potwierdzające udział.
Firma pokazuje listę obecności, ale nie pokazuje, czy szkolenie zmieniło zachowania. Dobrze jest mierzyć zgłoszenia phishingu, użycie drugiego kanału i wyniki ćwiczeń.
Bez logów i metryk trudno pokazać, że firma wykrywa incydenty, reaguje i poprawia zabezpieczenia.
Dobry raport z monitoringu pokazuje nie tylko liczbę alertów, ale też czas reakcji, status zamknięcia, właścicieli i działania naprawcze.
Zakres ISMS pokazuje, które procesy, lokalizacje, systemy, zespoły i usługi są objęte systemem zarządzania bezpieczeństwem informacji.
Dowód powinien pokazywać interesariuszy, wymagania prawne, wymagania klientów, czynniki wewnętrzne i zewnętrzne oraz wpływ tych elementów na ISMS.
ISO 27001 wymaga metodycznego podejścia do ryzyka. Dowodem jest metodyka, rejestr ryzyk, oceny, decyzje i plan działań.
SoA pokazuje, które kontrole są stosowane, które nie są stosowane i dlaczego. Powinien być spójny z oceną ryzyka.
Organizacja powinna mieć mierzalne cele bezpieczeństwa informacji, na przykład zamknięcie podatności wysokiego ryzyka, testy backupu, access review, szkolenia albo poprawę MFA.
Dowodem są plan audytów, checklista, raport audytu, niezgodności, obserwacje i działania korygujące.
Dowodem jest protokół przeglądu zarządzania, w tym status ryzyk, wyniki audytów, incydenty, metryki, działania korygujące i decyzje kierownictwa.
Dowodem są rejestr niezgodności, analiza przyczyn, plan korekty, właściciel, termin i potwierdzenie zamknięcia.
Trzeba pokazać, dlaczego firma uznała, że podlega albo nie podlega regulacji. To powinien być udokumentowany wniosek, a nie ustna opinia.
Jeśli firma jest podmiotem kluczowym albo ważnym, powinna mieć dowód wpisu, decyzji, kwalifikacji albo innego potwierdzenia zgodnie z właściwym trybem krajowym.
Trzeba mieć procedurę i szablony dla pierwszych godzin incydentu. Dowody powinny obejmować testy procesu zgłaszania, a nie tylko opis w dokumencie.
Dowodem są raporty dla zarządu, decyzje, szkolenia, zatwierdzone plany i budżet.
KSC może przewidywać możliwość żądania dokumentów, informacji i dowodów realizacji wymogów. Dlatego pakiet dowodów powinien być gotowy przed kontrolą, a nie tworzony dopiero po wezwaniu.
Repozytorium dowodów powinno być uporządkowane, bezpieczne i łatwe do przeglądu. Nie powinno być folderem, do którego każdy wrzuca przypadkowe pliki.
Nie każdy plik jest dobrym dowodem. Dowód powinien być wiarygodny, aktualny i powiązany z wymaganiem.
Polityka mówi, co powinno się dziać. Dowód pokazuje, co faktycznie się wydarzyło.
Jeżeli nikt nie odpowiada za dowód, szybko staje się przeterminowany.
Podczas audytu firma traci czas na szukanie plików, a część dowodów znika razem z właścicielem folderu.
Audytor musi wiedzieć, czy dowód jest aktualny. Brak daty osłabia wiarygodność.
Firma ma plan backupu, BCP albo incident response, ale nie ma raportu z testu. To bardzo częsta luka.
Zarząd omawia cyberbezpieczeństwo, ale nie ma protokołu, decyzji, budżetu ani akceptacji ryzyka.
Firma ma wiele plików, ale nie wie, które wymaganie każdy plik potwierdza.
Raport z podatności albo audytu nie wystarczy. Trzeba pokazać, co poprawiono, kiedy i kto zatwierdził zamknięcie.
Firma SaaS przygotowuje się do wymagań klienta enterprise, NIS2 i ISO 27001. Zespół IT ma wiele dobrych praktyk: MFA, backup, monitoring, skany podatności i szkolenia. Problem pojawia się podczas audytu klienta. Firma nie potrafi szybko pokazać, kiedy wykonano ostatni restore, kto zatwierdził access review, jakie ryzyka zaakceptował zarząd i czy dostawcy krytyczni byli ocenieni.
Firma tworzy macierz dowodów. Każdy obszar kontroli dostaje właściciela, lokalizację plików, częstotliwość aktualizacji i status. W ciągu 90 dni firma porządkuje rejestr ryzyk, Statement of Applicability, raporty backupu, access review, szkolenia, dostawców, podatności i incident response.
Efekt: podczas kolejnego audytu firma nie szuka dowodów chaotycznie. Pokazuje pakiet dowodowy: co jest wymagane, jaki dowód istnieje, kiedy został zaktualizowany i jakie działania naprawcze są w toku. To skraca audyt i zwiększa wiarygodność wobec klienta, zarządu i ubezpieczyciela.
ccyber.io pomaga firmom przygotować praktyczny pakiet dowodów zgodności pod NIS2, KSC, ISO 27001, audyty klientów i cyberubezpieczenie. Nie tworzymy dokumentów dla dokumentów. Budujemy system dowodowy, który pokazuje, że kontrole działają w praktyce.
Możemy wesprzeć organizację w obszarach:
Najlepszym pierwszym krokiem jest Compliance Evidence Workshop. W krótkim warsztacie można ustalić, jakie dowody już istnieją, czego brakuje, które dowody są przeterminowane i jak zbudować pakiet gotowy dla zarządu, audytora, klienta albo organu nadzoru.
Nie. Polityka jest potrzebna, ale trzeba pokazać dowody działania: raporty, testy, przeglądy, logi, decyzje i działania naprawcze.
Analiza podlegania, rejestr ryzyk, plan działań, polityka bezpieczeństwa, raport MFA, access review, test restore, plan incydentowy, ocena dostawców i dowody szkoleń.
Tak. Wiele dowodów może wspierać kilka wymagań jednocześnie. Dlatego warto stworzyć macierz dowodów i mapować je do różnych regulacji oraz standardów.
To zależy od obszaru. Ryzyka, dostawcy, access review, backup, szkolenia i podatności powinny mieć ustaloną częstotliwość przeglądu, zwykle kwartalną, półroczną albo roczną.
Brak testów. Firmy mają procedury backupu, incident response albo BCP, ale nie mają raportów pokazujących, że proces był przećwiczony.
Nie automatycznie. ISO 27001 bardzo pomaga, ale trzeba osobno sprawdzić wymagania NIS2, KSC, zgłaszanie incydentów, zakres regulacji i przepisy krajowe.
Najczęściej compliance, CISO, vCISO, risk albo osoba odpowiedzialna za ISMS. Właściciele poszczególnych dowodów powinni być w IT, security, HR, legal, zakupach, finansach i biznesie.
Zacznij od macierzy dowodów: wymaganie, dowód, właściciel, data, status i luka. Następnie uzupełnij najważniejsze obszary: ryzyko, dostęp, backup, incydenty, dostawcy i szkolenia.
Dowody zgodności pod NIS2, KSC i ISO 27001 powinny pokazywać realne działanie cyberbezpieczeństwa. Sama polityka, prezentacja albo deklaracja nie wystarczy. Potrzebne są raporty, testy, logi, decyzje, przeglądy i działania korygujące.
Najważniejsze grupy dowodów to: zakres i podleganie, decyzje zarządu, ryzyko, polityki, Statement of Applicability, kontrola dostępu, backup, incident response, podatności, dostawcy, szkolenia, monitoring, audyty i działania naprawcze.
Najlepsze podejście to jedno repozytorium i jedna macierz dowodów, która łączy wymagania NIS2, KSC, ISO 27001, klientów i ubezpieczycieli. Wtedy firma nie przygotowuje się do audytu w panice. Ma system dowodowy, który działa na co dzień.
Piszemy o regulacjach takich jak NIS2, DORA, CRA i ISO 27001, o bezpieczeństwie MŚP i infrastruktury krytycznej, a także o cyberhigienie, cyberzagrożeniach i budowaniu świadomości bezpieczeństwa w organizacji.
Każdy artykuł to praktyczna wiedza - bez żargonu i z konkretnymi wskazówkami do wdrożenia, które pomagają firmom skutecznie chronić dane, ludzi i ciągłość działania.