01
Samoidentyfikacja to osobny projekt
Kancelaria rekomenduje nie zaczynać od wzoru polityki bezpieczeństwa. Najpierw trzeba ustalić sektor, rozmiar, faktyczną działalność, wpis do Wykazu KSC i właściwy zakres usług.
Specjaliści rekomendują
KSC 2 trzeba wdrożyć operacyjnie, a nie wyłącznie dokumentacyjnie.
W doktrynie i praktyce audytowej powtarza się ten sam wniosek: KSC 2 działa podobnie jak RODO w obszarze rozliczalności. Organizacja powinna umieć pokazać analizę ryzyka, decyzje, właścicieli procesów i dowody wykonania obowiązków.
02
Audytor szuka dowodów, nie deklaracji
Polityka incydentowa bez rejestru incydentów, backup bez testu odtworzeniowego i patch management bez terminów to typowe czerwone flagi.
03
RODO nauczyło nas rozliczalności
Tak jak przy RODO, sama procedura nie wystarczy. Organizacja musi wykazać, że przeanalizowała ryzyko, podjęła decyzje i wdrożyła adekwatne środki.
Etap 1: status podmiotu
Czy Twoja firma podlega KSC 2?
Najczęstsze pytanie po wejściu w życie KSC 2 brzmi: „czy my w ogóle podlegamy?”. Odpowiedź wymaga analizy realnej działalności, a nie jedynie kodów PKD. Jeżeli organizacja faktycznie świadczy usługę objętą ustawą, brak właściwego PKD nie musi jej chronić. Jeżeli ma PKD „na zapas”, ale działalności nie wykonuje, również trzeba to rzetelnie udokumentować.
- sprawdź sektor i podsektor działalności,
- zweryfikuj progi wielkości i powiązania kapitałowe,
- ustal, czy jesteś wpisany z urzędu, czy musisz dokonać samorejestracji,
- zbadaj, czy świadczysz usługi zarządzane lub usługi cyberbezpieczeństwa,
- opisz tok rozumowania - to pierwszy dowód należytej staranności.
Etap 2: audytowalność
Audytor nie zapyta tylko „czy macie procedurę?”. Zapyta: „pokażcie dowód”.
Kancelaria rekomenduje budować system tak, aby każdy proces miał właściciela, procedurę, narzędzie, miernik oraz ślad działania.
Dokumentacja ma opisywać rzeczywistość.
Polityka bezpieczeństwa, procedura incydentowa czy plan ciągłości działania nie mogą być katalogiem życzeń. Mają pokazywać, kto robi co, w jakim terminie, w jakim systemie i jak powstaje dowód.
- procedura + właściciel procesu,
- rejestr działań i decyzji,
- aktualizacja po testach i incydentach.
Monitorowanie to nie zawsze SOC 24/7.
W praktyce nie chodzi wyłącznie o posiadanie rozbudowanego SOC 24/7. Kluczowe jest to, czy organizacja nie ma „czarnych dziur” w logach i czy potrafi ustalić, co działo się w systemach istotnych dla świadczenia usługi.
- ciągłość zbierania logów dla systemów istotnych,
- alerty i eskalacja po godzinach,
- procedura analizy i dowody reakcji.
Incydent musi mieć rejestr, role i lessons learned.
Procedura bez rejestru incydentów nie obroni się w audycie. Rejestr pozwala wykazać czas wykrycia, decyzję o kwalifikacji, komunikację z CSIRT, działania naprawcze i wnioski po zdarzeniu.
- wczesne ostrzeżenie i zgłoszenie w terminach ustawowych,
- kto kwalifikuje incydent, a kto zatwierdza zgłoszenie,
- wnioski po incydencie trafiają do zarządu.
Backup nietestowany nie istnieje.
Większość firm deklaruje, że robi kopie zapasowe. Audytor zapyta jednak, kiedy ostatnio odtworzono dane, czy test miał protokół i czy dostęp do backupu nie zależy od tego samego środowiska, które może zostać zaszyfrowane.
- zasada 3-2-1 jako punkt startowy,
- test odtworzenia dla kluczowych systemów,
- protokół, wynik testu i plan korekty.
Twoja organizacja jest tak bezpieczna, jak jej najsłabszy dostawca.
Nie każdy dostawca wymaga ankiety z 240 pytaniami. Potrzebna jest klasyfikacja ryzyka, minimalne wymagania bezpieczeństwa, zapisy umowne i dowody weryfikacji dostawców krytycznych.
- MFA, szyfrowanie i patch management po stronie dostawcy,
- obowiązek zgłaszania incydentów,
- prawo do audytu albo równoważne dowody bezpieczeństwa.
Pytania audytowe
Czego można spodziewać się w ramach audytu KSC 2?
Audyt KSC 2 w praktyce nie kończy się na sprawdzeniu, czy organizacja ma polityki i procedury. Audytor będzie weryfikował, czy procesy faktycznie działają i czy pozostawiają ślad dowodowy.
- Kiedy ostatnio testowano odtworzenie danych z backupu?
- Czy istnieje protokół z testu odtworzeniowego?
- Czy rejestr ryzyka był aktualizowany po zmianach, incydentach lub testach?
- Czy zarząd zatwierdził polityki i procedury bezpieczeństwa?
- Kto jest właścicielem procesu: backupu, incydentów, dostępu, podatności i dostawców?
- Czy dostawcy byli oceniani pod kątem ryzyka cyberbezpieczeństwa?
- Czy umowy zawierają wymagania bezpieczeństwa i obowiązki zgłaszania incydentów?
- Czy istnieją logi i ślady obsługi incydentu: zgłoszenia, decyzje, eskalacje i działania naprawcze?
Praktyczny poradnik
Jak przygotować się do takich pytań?
- przypisz właściciela każdego procesu: backupu, incydentów, dostępu, podatności, dostawców i raportowania do zarządu,
- dla każdego pytania wskaż konkretny dowód: rejestr, protokół, log, zgłoszenie, raport, uchwałę, notatkę zarządczą albo wpis w systemie ticketowym,
- sprawdź, czy procedura opisuje realne działanie organizacji, a nie model życzeniowy przygotowany wyłącznie pod kontrolę,
- przygotuj matrycę audytową: pytanie, właściciel, wymagany dowód, lokalizacja dowodu, data ostatniego testu lub przeglądu, luka i termin korekty,
- zamykaj luki zadaniami z terminem i osobą odpowiedzialną, bo audytor będzie pytał nie tylko o brak, ale też o plan naprawczy.
Typowe problemy
Gdzie najczęściej pojawiają się luki?
W praktyce najwięcej trudności dotyczy podstawowych procesów technicznych i organizacyjnych. To one powinny wejść do pierwszej rundy audytu wewnętrznego.
inwentaryzacja aktywów
zarządzanie podatnościami
patch management
MFA i kontrola dostępu
konta współdzielone
segmentacja sieci
monitoring logów
backup
testy odtworzeniowe
zarządzanie dostawcami
Czerwone flagi
Co najczęściej zdradza papierowe wdrożenie?
Najważniejsze czerwone flagi to elementy, które Kancelaria rekomenduje sprawdzić przed audytem, kontrolą albo rozmową z kontrahentem.
Procedura zarządzania incydentami bez rejestru incydentów
Jeżeli procedura istnieje, ale nie ma zgłoszeń, logów, decyzji i lessons learned, audytor uzna, że proces nie działa albo nie jest dowodowy.
Brak logów i zgłoszeń
Bez logów, zgłoszeń i ścieżki eskalacji organizacja nie jest w stanie wykazać, kiedy zdarzenie wykryto, kto je obsługiwał i jakie decyzje podjęto.
Brak wniosków po incydencie, czyli brak lessons learned
Incydent powinien kończyć się korektą procesu: zmianą konfiguracji, aktualizacją procedury, szkoleniem, decyzją zarządu albo wpisem do rejestru ryzyka.
Patch management opisany w procedurze, ale niewykonywany terminowo
Sama procedura CVSS nie wystarczy. Trzeba pokazać wyniki skanów, ocenę krytyczności, decyzję, termin wdrożenia poprawki i ewentualną akceptację ryzyka.
Testy odtworzeniowe opisane w planie, ale nigdy nieprzeprowadzone
Plan Disaster Recovery przygotowany w dokumencie, ale nigdy nietestowany, nie daje pewności ciągłości działania. Test powinien zostawić protokół i listę korekt.
Brak KPI i KRI dla procesów bezpieczeństwa
Bez mierników procesu organizacja nie wie, czy poprawki są wdrażane terminowo, czy podatności wracają, czy szkolenia działają i czy incydenty są obsługiwane zgodnie z procedurą.
Brak informacji zarządczej
Zarząd musi mieć dane, nie ogólne zapewnienia. Kancelaria rekomenduje cykliczny raport o ryzyku, incydentach, podatnościach, backupach, szkoleniach i dostawcach.
Brak przeglądów
Nieaktualizowana dokumentacja, rejestr ryzyka bez daty przeglądu i nieprzeglądane uprawnienia świadczą o tym, że system nie jest utrzymywany.
Brak właścicieli procesów
Jeżeli nikt nie odpowiada za dostęp, incydenty, backup, dostawców i analizę ryzyka, to proces istnieje wyłącznie w dokumencie.
Dokumenty stworzone tylko „pod kontrolę”
Dokumentacja przygotowana bez odniesienia do narzędzi, systemów, osób odpowiedzialnych i realnych dowodów zwykle rozpada się przy pierwszych pytaniach audytora.
TOP 8 działań operacyjnych
Od czego Kancelaria rekomenduje zacząć?
To nie jest pełne wdrożenie KSC 2, ale zestaw działań, które najczęściej dają szybki wzrost odporności i przygotowują materiał dowodowy do audytu.
Inwentaryzacja aktywów
Nie ochronisz systemu, o którego istnieniu nie wiesz. Zacznij od mapy systemów, aplikacji, kont, integracji i dostawców.
MFA i kontrola dostępu
Wyeliminuj konta współdzielone, uporządkuj uprawnienia, włącz MFA dla systemów krytycznych i kont uprzywilejowanych.
Podatności i poprawki
Użyj skanera, priorytetyzuj krytyczne zasoby, dokumentuj decyzje i wdrażaj poprawki w terminach wynikających z ryzyka.
Logi i incydenty
Zbieraj logi tam, gdzie ma to znaczenie, ustaw alerty, stwórz ścieżkę eskalacji i prowadź rejestr incydentów.
Backup i odtworzenie
Stosuj zasadę 3-2-1, sprawdź odporność kopii na ransomware i wykonaj test odtworzenia dla kluczowych systemów.
Dostawcy
Klasyfikuj dostawców według ryzyka. Weryfikuj MFA, szyfrowanie, patch management, incydenty i zapisy umowne.
Security Awareness
Szkolenie nie może być jednorazowe. Kancelaria we współpracy z SECAWA rekomenduje Praktyczny Trening Antyphishingowy, regularne szkolenia Security Awareness, Testy Socjotechniczne i Penetracyjne oraz stały dostęp do e-learningu.
Raport dla zarządu
Zarząd powinien otrzymywać zwięzłą informację: ryzyka, decyzje, koszty, priorytety, incydenty, terminy i odpowiedzialność.
Mini-samodiagnoza
Zaznacz, co już działa w Twojej organizacji.
Plan działania
90 dni, które porządkują wdrożenie KSC 2.
Nie jest to obietnica pełnej zgodności w 90 dni. To realistyczny szkielet projektu, który pozwala przejść od chaosu do mierzalnego programu działań.
Dni 1-30
Diagnoza i kwalifikacja
- walidacja statusu KSC,
- mapa procesów i systemów,
- właściciele procesów,
- wstępny rejestr ryzyk,
- raport startowy dla zarządu.
Dni 31-60
Quick wins i dowody
- MFA i konta uprzywilejowane,
- logi i alerty dla systemów krytycznych,
- backup i pierwszy test odtworzenia,
- rejestr incydentów,
- minimalne wymagania dla dostawców.
Dni 61-90
Audytowalność i szkolenia
- procedury dopasowane do rzeczywistości,
- ćwiczenie incydentowe,
- Security Awareness i antyphishing,
- plan ciągłości działania,
- raport zgodności i backlog działań.
Kancelaria + SECAWA
Prawo, audyt i realna odporność zespołu.
Kancelaria we współpracy z SECAWA rekomenduje połączenie audytu prawnego, analizy procesów i praktycznych działań technicznych z edukacją pracowników. KSC 2 wymaga systemu, który da się obronić przed audytorem i który zadziała w chwili incydentu.
Terminy i odpowiedzialność
Nie czekaj na audyt. Zbuduj dowody wcześniej.
Nowelizacja KSC weszła w życie 3 kwietnia 2026 r. Co do zasady nowo objęte podmioty powinny dokonać wpisu do Wykazu KSC do 3 października 2026 r., wdrożyć obowiązki do 3 kwietnia 2027 r., a wybrane podmioty kluczowe przygotować się na pierwszy audyt do 3 kwietnia 2028 r.
Kancelaria rekomenduje traktować te daty jako harmonogram projektu: najpierw status, potem analiza ryzyka, następnie środki techniczne, dokumentacja, szkolenia, dostawcy i audytowalny materiał dowodowy.
„Regulacje NIS2/KSC2 przesuwają rozmowę z poziomu 'jakie dokumenty trzeba mieć' na poziom 'jak udowodnić, że bezpieczeństwo działa'.”
Wniosek praktyczny z doświadczeń wdrożeniowych UKSC/NIS2
Q&A
Najczęstsze pytania o wdrożenie KSC 2 w organizacji.
Poniższe odpowiedzi zbierają praktyczne wątki, które najczęściej pojawiają się podczas szkoleń, konsultacji i przygotowań do audytu: od kwalifikacji podmiotu, przez procedury incydentowe, po dowody działania systemu.
Czy KSC 2 dotyczy tylko dużych firm?
Nie zawsze. Wielkość przedsiębiorstwa jest ważnym kryterium, ale nie jest jedynym elementem analizy. Znaczenie mają także sektor, rodzaj faktycznie świadczonych usług, rola organizacji w łańcuchu dostaw oraz to, czy dana usługa jest objęta ustawą.
Kancelaria rekomenduje nie kończyć analizy na prostym pytaniu o liczbę pracowników. Należy udokumentować tok samoidentyfikacji i wskazać, dlaczego organizacja uznaje się za objętą albo nieobjętą KSC 2.
Czy wystarczy sprawdzić kody PKD?
Nie. PKD może być pomocnym sygnałem, ale nie powinno zastępować analizy realnej działalności. Organizacja może mieć PKD wpisane „na zapas”, ale nie wykonywać danej działalności. Może też faktycznie świadczyć usługę objętą KSC 2, mimo że PKD nie oddaje tego precyzyjnie.
W praktyce warto porównać PKD, umowy, opis usług, procesy operacyjne, strukturę przychodów, systemy IT i zależności od dostawców.
Od czego zacząć wdrożenie KSC 2?
Najpierw od kwalifikacji. Kancelaria rekomenduje kolejność: status podmiotu, mapa usług objętych ustawą, mapa procesów, mapa systemów informacyjnych, właściciele procesów, analiza ryzyka, a dopiero potem dokumentacja i wdrożenie środków technicznych.
Zakup gotowej dokumentacji bez wcześniejszego ustalenia statusu i zakresu obowiązków zwykle prowadzi do papierowego wdrożenia, którego trudno bronić w audycie.
Co oznacza „monitorowanie ciągłe” w praktyce?
Nie w każdej organizacji musi to oznaczać pełny SOC 24/7. Kluczowe jest ustalenie, które systemy wspierają usługi objęte ustawą, jakie logi są potrzebne, kto je analizuje, kiedy powstaje alert i jak wygląda eskalacja po godzinach pracy.
Audytowo najważniejsze jest to, aby nie było „czarnych dziur”: organizacja powinna umieć odtworzyć, co działo się w systemach i kto podjął decyzję po wykryciu zdarzenia.
Jak przygotować procedurę incydentową z terminami 24/72 godziny?
Procedura powinna wskazywać, kto wykrywa zdarzenie, kto je kwalifikuje, kto zatwierdza zgłoszenie, kto komunikuje się z CSIRT i kto odpowiada za działania naprawcze. Terminy 24/72 godziny powinny być przełożone na realny proces decyzyjny w organizacji.
Kancelaria rekomenduje przygotować prostą kartę incydentu: data i godzina wykrycia, osoba zgłaszająca, kwalifikacja, decyzje, kontakt z CSIRT, działania techniczne, komunikacja wewnętrzna, lessons learned.
Kto powinien odpowiadać za S46 i kontakt z CSIRT?
Warto wyznaczyć co najmniej osoby podstawowe i zastępcze: po stronie IT/cyberbezpieczeństwa, po stronie prawno-compliance oraz po stronie zarządczej. Chodzi o to, aby w chwili incydentu nie ustalać dopiero, kto ma konto, uprawnienia i kompetencję do zatwierdzenia zgłoszenia.
Dobrym rozwiązaniem jest krótka matryca odpowiedzialności: kto przygotowuje dane techniczne, kto ocenia obowiązek zgłoszenia, kto akceptuje treść i kto utrzymuje kontakt z CSIRT.
Czy automatyczny backup wystarczy?
Nie. Backup, którego nigdy nie odtworzono, jest deklaracją, a nie dowodem odporności. Audytor będzie pytał o datę testu, zakres testu, protokół, wynik, wykryte problemy i plan korekt.
Kancelaria rekomenduje zacząć od testów odtworzeniowych dla systemów krytycznych oraz sprawdzić, czy kopia jest odporna na scenariusz ransomware i czy dostęp do backupu nie zależy od tego samego środowiska, które może zostać naruszone.
Jak traktować systemy legacy?
Nie można ich pominąć tylko dlatego, że są stare, trudne w utrzymaniu albo „nietykalne biznesowo”. Jeżeli wspierają proces objęty ustawą, powinny wejść do inwentaryzacji, analizy ryzyka, planu ciągłości działania i planu zabezpieczeń kompensacyjnych.
W praktyce należy opisać ograniczenia, podatności, zależności od dostawców, możliwości segmentacji, monitoring, backup i plan migracji albo utrzymania ryzyka na akceptowalnym poziomie.
Co zrobić z dostawcami IT i cyberbezpieczeństwa?
Dostawców trzeba sklasyfikować według ryzyka. Inaczej ocenia się dostawcę systemu krytycznego, operatora chmury, firmę utrzymaniową, SOC, dostawcę pentestów, a inaczej zwykłego dostawcę pomocniczego.
Minimalny pakiet to: ocena ryzyka, wymagania bezpieczeństwa w umowie, obowiązek zgłaszania incydentów, wymagania MFA i kontroli dostępu, zasady podwykonawstwa, prawo do audytu albo równoważne dowody bezpieczeństwa.
Jakie dowody działania systemu warto przygotować przed audytem?
Najważniejsze są dowody operacyjne: rejestr ryzyka, rejestr incydentów, logi i alerty, protokoły testów backupu, raporty z podatności, ślady patch managementu, przeglądy uprawnień, raporty dla zarządu, oceny dostawców i potwierdzenia szkoleń.
Dokumentacja jest potrzebna, ale sama nie wystarczy. Audytor będzie sprawdzał, czy organizacja potrafi pokazać, że procedury działają w praktyce.
Czy zarząd musi być zaangażowany w KSC 2?
Tak. KSC 2 nie jest wyłącznie projektem IT. To projekt zarządczy, bo dotyczy ryzyka, ciągłości działania, kosztów, odpowiedzialności, dostawców, priorytetów i decyzji o akceptacji ryzyka.
Kancelaria rekomenduje cykliczną informację zarządczą: status wdrożenia, najważniejsze ryzyka, incydenty, podatności, testy odtworzeniowe, dostawcy, szkolenia i decyzje wymagające zatwierdzenia.
Czy można wdrażać KSC 2 etapami?
Tak, a w praktyce często jest to jedyne rozsądne podejście. Ważne, aby etapowanie wynikało z analizy ryzyka, a nie z przypadkowej kolejności działań.
Najpierw warto zabezpieczyć obszary o największym znaczeniu: kwalifikację statusu, procesy krytyczne, MFA, konta uprzywilejowane, logi, incydenty, backup, dostawców i raportowanie do zarządu. Resztę można ująć w backlogu z właścicielami i terminami.
Co dalej?
Sprawdź obowiązki, zanim kupisz dokumentację.
Kancelaria rekomenduje rozpocząć od krótkiego zapytania i audytu bezpieczeństwa. Dzięki temu ustalisz, czy podlegasz KSC 2, jakie procesy są krytyczne, gdzie brakuje dowodów i jakie działania trzeba wykonać przed audytem.
Podstawa opracowania: analiza obowiązków UKSC/NIS2, praktyki audytowej, podejścia Ministerstwa Cyfryzacji do KSC 2 oraz analogii do RODO w obszarze rozliczalności i zarządzania ryzykiem. Stan prawny: 16 czerwca 2026 r.
Źródła pomocnicze: ustawa o krajowym systemie cyberbezpieczeństwa po nowelizacji, materiały Ministerstwa Cyfryzacji dotyczące obowiązków podmiotów kluczowych i ważnych, materiały i informacje jako wnioski pokonferencyjne.
