Ustawa o KSC: 13 obowiązków, które musisz wdrożyć
Wiesz już, że Twoja firma podlega ustawie o Krajowym Systemie Cyberbezpieczeństwa (ustawa o KSC). Wiesz, do kiedy musisz się zarejestrować i ile grozi za brak zgodności. Jeśli jeszcze tego nie sprawdziłeś, zrób to najpierw – wypełnij naszą krótką ankietę samoidentyfikacji, zanim zaczniesz wdrażać obowiązki opisane poniżej.
Zostaje najtrudniejsze pytanie: co dokładnie masz wdrożyć?
Ustawa nie ogranicza się do jednego obowiązku pod nazwą „bezpieczeństwo”. To kilkanaście osobnych wymogów:
- część techniczna,
- część organizacyjna,
- część czysto proceduralna.
Poniżej rozpisujemy każdy z nich osobno: co oznacza, jak wygląda w praktyce i czego będzie od Ciebie oczekiwał audytor lub kontrola.
1. Rejestracja w wykazie podmiotów kluczowych i ważnych
To pierwszy obowiązek i jednocześnie warunek formalny do wszystkich pozostałych. Bez wpisu do wykazu nie masz oficjalnie potwierdzonego statusu.
W praktyce oznacza to złożenie wniosku przez system teleinformatyczny S46, w którym podajesz dane identyfikacyjne firmy, sektor działalności, osoby wyznaczone do kontaktu oraz podstawę prawną uznania się za podmiot kluczowy lub ważny. Wniosek składasz samodzielnie na podstawie własnej samoidentyfikacji, nie na wezwanie organu. Po wpisie obowiązki nie znikają: każdą zmianę danych (np. adresu, osoby kontaktowej, zakresu działalności) zgłaszasz w ciągu 14 dni. Jeśli firma przestanie spełniać kryteria (np. spadnie poniżej progu zatrudnienia) masz obowiązek złożyć wniosek o wykreślenie z wykazu, a nie po prostu przestać się nim zajmować.
2. Analiza i zarządzanie ryzykiem
To fundament, od którego zaczyna się cały system zarządzania bezpieczeństwem informacji (SZBI). Wszystkie pozostałe środki muszą z niego wynikać, a nie być wdrażane „na wszelki wypadek”.
Konkretnie oznacza to trzy elementy udokumentowane i aktualizowane:
- rejestr aktywów (jakie systemy, dane i procesy masz i kto za nie odpowiada),
- mapowanie zagrożeń i podatności (np. w oparciu o uznane standardy ISO 27005 albo NIST CSF) oraz
- macierz ryzyka łączącą prawdopodobieństwo wystąpienia zagrożenia z jego potencjalnym wpływem na działalność.
Na tej podstawie tworzysz plan postępowania z ryzykiem. Decydujesz, które ryzyka mitygujesz technicznie, które transferujesz (np. ubezpieczeniem), a które świadomie akceptujesz. Analizę aktualizujesz nie rzadziej niż raz w roku oraz niezwłocznie po incydencie lub istotnej zmianie w infrastrukturze. To właśnie ten dokument jako pierwszy zobaczy audytor, bo z niego wynika, czy dobrane środki techniczne są w ogóle uzasadnione.
3. Polityka bezpieczeństwa i dokumentacja
Każdy środek techniczny musi mieć odzwierciedlenie w dokumencie. Inaczej z punktu widzenia kontroli po prostu nie istnieje.
Ustawa (art. 10) rozróżnia dwie warstwy dokumentacji.
Dokumentacja normatywna to polityki i procedury: nadrzędna Polityka Bezpieczeństwa Informacji podpisana przez zarząd, a pod nią polityki szczegółowe: kontroli dostępu, kryptografii, pracy zdalnej, kopii zapasowych, klasyfikacji informacji, zarządzania incydentem, zarządzania podatnościami.
Dokumentacja operacyjna to dowód, że te polityki faktycznie są stosowane: logi systemowe, protokoły z testów, rejestry szkoleń, raporty z przeglądów. Całość przechowujesz co najmniej 2 lata od wycofania danego dokumentu z użycia. W praktyce: sama polityka „na papierze” nic nie daje, jeśli nie potrafisz pokazać zapisów potwierdzających jej realizację.
4. Kontrola dostępu, zarządzanie aktywami i kryptografia
Chodzi o to, żeby dostęp do systemów i danych miały tylko uprawnione osoby i żeby dało się to w każdej chwili wykazać.
W praktyce: rejestr aktywów IT (sprzęt, oprogramowanie, dane) z przypisaną odpowiedzialnością za każdy z nich, zasada minimalnych uprawnień (dostęp tylko do tego, co niezbędne do wykonywania obowiązków), regularne przeglądy nadanych uprawnień, szczególnie po zmianie stanowiska lub odejściu pracownika. Do tego dochodzi kryptografia: szyfrowanie danych w spoczynku i w trakcie przesyłania, oraz uwierzytelnianie wieloskładnikowe (MFA) – obowiązkowe przede wszystkim dla dostępu zdalnego i kont uprzywilejowanych (administratorzy, systemy krytyczne). To jeden z tych obszarów, gdzie brak wdrożenia widać najszybciej podczas testu penetracyjnego czy audytu.
5. Bezpieczeństwo systemów oraz bezpieczeństwo fizyczne i środowiskowe
Ten obowiązek obejmuje zarówno cyfrową, jak i fizyczną stronę infrastruktury. Jedno bez drugiego nie daje realnego bezpieczeństwa.
Po stronie systemów: bezpieczne pozyskiwanie i wdrażanie oprogramowania, zarządzanie podatnościami i aktualizacjami (proces łatania, nie przypadkowe „zainstaluje się kiedyś”), testy bezpieczeństwa przed wdrożeniem zmian, a przy wycofywaniu systemu z użycia – bezpieczne usunięcie danych. Po stronie fizycznej: kontrola dostępu do pomieszczeń, w których znajduje się infrastruktura (serwerownie, szafy krosowe) oraz zabezpieczenie przed zagrożeniami środowiskowymi: pożarem, zalaniem, przerwą w zasilaniu (UPS, agregaty). Dla firm korzystających z chmury lub kolokacji ten obowiązek w dużej mierze przechodzi na dostawcę, ale odpowiedzialność za jego wyegzekwowanie zostaje po Twojej stronie.
6. Bezpieczeństwo zasobów ludzkich
Największe ryzyko w cyberbezpieczeństwie generują ludzie, dlatego ustawa traktuje ten obszar jako osobny obowiązek, a nie dodatek do polityki IT.
W praktyce: osoby faktycznie realizujące zadania z zakresu SZBI lub obsługi incydentów muszą przedstawić zaświadczenie o niekaralności za przestępstwa przeciwko ochronie informacji, a kierownik podmiotu może zażądać go ponownie w razie uzasadnionych wątpliwości. Do tego dochodzą umowy o zachowaniu poufności, procedury onboardingu (nadawanie dostępów proporcjonalnych do roli) i równie ważne offboardingu, czyli natychmiastowego odbierania dostępów po zakończeniu współpracy. To jeden z najczęściej pomijanych elementów: firmy pilnują nadawania uprawnień, zapominają o ich odbieraniu.
7. Ciągłość działania i zarządzanie kryzysowe
Chodzi o to, żeby firma przetrwała poważny incydent operacyjnie, nie tylko formalnie go zgłosiła.
W praktyce oznacza to opracowanie, przetestowanie i utrzymywanie planu ciągłości działania (BCP) oraz planu odzyskiwania po awarii (DRP) ze scenariuszami dopasowanymi do realnych zagrożeń: atak ransomware, awaria dostawcy chmurowego, długotrwała przerwa w zasilaniu. Każdy scenariusz powinien mieć określone RTO i RPO (maksymalny akceptowalny czas przestoju i maksymalną akceptowalną utratę danych), listę kontaktową i konkretne kroki odbudowy. Kluczowe słowo to „przetestowany” – plan, który istnieje tylko jako dokument i nigdy nie był ćwiczony, nie spełnia intencji ustawy, nawet jeśli formalnie jest.
8. Ciągłe monitorowanie
Ustawa wymaga wykrywania zagrożeń na bieżąco, nie dopiero po fakcie, gdy incydent już wyrządził szkodę.
W praktyce oznacza to wdrożenie narzędzi klasy SIEM (agregacja i analiza logów) lub skorzystanie z usługi SOC (zespołu monitorującego bezpieczeństwo 24/7), które wykrywają anomalie i próby nieautoryzowanego dostępu w czasie zbliżonym do rzeczywistego. Monitorowanie musi być zintegrowane z procesem obsługi incydentów – wykrycie anomalii powinno automatycznie uruchamiać procedurę oceny, czy mamy do czynienia z incydentem podlegającym zgłoszeniu.
9. Bezpieczeństwo łańcucha dostaw
Twoje bezpieczeństwo jest tak dobre, jak bezpieczeństwo Twoich dostawców – ustawa wprost każe to weryfikować, a nie zakładać na słowo.
W praktyce: ocena ryzyka dostawców i usługodawców przed podpisaniem umowy, a w ślad za nią zwykle klauzule bezpieczeństwa w kontraktach (terminy zgłaszania incydentów, prawo do audytu, przejrzystość podwykonawców) oraz bieżące monitorowanie zgodności dostawcy przez cały okres współpracy.
10. Edukacja personelu i cyberhigiena
Najlepsze zabezpieczenia techniczne nie pomogą, jeśli pracownik kliknie w link z phishingu, dlatego ustawa traktuje szkolenia jako osobny, obowiązkowy element systemu.
Dla wszystkich pracowników: regularne szkolenia z rozpoznawania phishingu, bezpiecznego zarządzania hasłami, zasad korzystania z urządzeń służbowych i prywatnych (BYOD) oraz podstawowych zasad cyberhigieny. To osobny wymóg od corocznego, udokumentowanego szkolenia dla zarządu. Kierownictwo musi przejść własne, ukierunkowane na odpowiedzialność zarządczą szkolenie, a jego brak jest samodzielną podstawą odpowiedzialności kierownika podmiotu.
11. Osoby kontaktowe i zgłaszanie incydentów
To jeden z najbardziej „na żywo” testowanych obowiązków sprawdzany nie na papierze, tylko w momencie realnego zdarzenia.
Zaczyna się od wyznaczenia co najmniej dwóch osób do kontaktu z właściwym CSIRT (art. 9) oraz zapewnienia pracownikom wiedzy o tym, jak rozpoznać i zgłosić incydent. Jeśli dojdzie do poważnego incydentu, obowiązują trzy twarde terminy (art. 11–12b):
Termin | Co zgłaszasz |
|---|---|
| 24 godziny od wykrycia | Wczesne ostrzeżenie do właściwego CSIRT (NASK, GOV lub MON). |
| 72 godziny od wykrycia | Zgłoszenie incydentu z klasyfikacją i wstępną oceną skutków. |
| 1 miesiąc od zgłoszenia | Sprawozdanie końcowe (przy dłuższej obsłudze — także raporty okresowe w trakcie). |
Kluczowa trudność w praktyce to nie sam formularz zgłoszenia, tylko szybkość podjęcia decyzji „czy to już jest incydent poważny” dlatego kryteria klasyfikacji powinny być ustalone i przećwiczone, zanim zdarzenie faktycznie wystąpi.
12. Ocena skuteczności wdrożonych środków
Ustawa nie pozwala wdrożyć systemu raz i o nim zapomnieć. Wymaga cyklicznego sprawdzania, czy faktycznie działa.
W praktyce oznacza to regularny, co do zasady coroczny, przegląd całego SZBI: czy polityki są aktualne, czy szkolenia się odbyły, czy plany ciągłości działania były testowane, czy poziom ryzyka się zmienił. Przegląd musi się odbyć także niezwłocznie po rekomendacji Pełnomocnika Rządu ds. Cyberbezpieczeństwa (w zakresie, w jakim dotyczy systemów, produktów lub usług ICT podmiotu) albo po wystąpieniu okoliczności istotnie zwiększających ryzyko, np. po głośnym ataku na firmę z tej samej branży.
13. Audyt bezpieczeństwa (podmioty kluczowe)
To zewnętrzna, niezależna weryfikacja wszystkiego powyżej i jedyny obowiązek z tej listy, który nie dotyczy podmiotów ważnych.
Art. 15 zobowiązuje podmioty kluczowe do przeprowadzenia pierwszego audytu bezpieczeństwa systemu informacyjnego w ciągu 24 miesięcy od spełnienia przesłanek, a kolejnych nie rzadziej niż raz na 3 lata. Audytor musi być niezależny: nie może to być osoba, która sama realizowała zadania SZBI w Twojej firmie w ciągu ostatniego roku. Raport z audytu przekazujesz organowi właściwemu w ciągu 3 dni roboczych od jego otrzymania. Jeśli masz już wdrożony system zgodny z ISO/IEC 27001 i ISO 22301, spełnienie wymogów tych norm daje – zgodnie ze stanowiskiem Ministerstwa Cyfryzacji – domniemanie zgodności z częścią wymogów SZBI. Nie zastępuje ono jednak wpisu do wykazu, zgłaszania incydentów do CSIRT ani obowiązku audytu; te wynikają wprost z ustawy niezależnie od certyfikatu.
Trzy pytania, które najczęściej słyszymy
Czy każda firma podlegająca ustawie o KSC musi przejść audyt bezpieczeństwa?
NIE. Obowiązek audytu dotyczy wyłącznie podmiotów kluczowych – podmioty ważne są z niego zwolnione, choć wszystkie pozostałe 12 obowiązków dotyczy obu kategorii.
Czy certyfikat ISO/IEC 27001 zwalnia z obowiązków wynikających z ustawy o KSC?
NIE. Daje domniemanie zgodności z częścią wymogów SZBI, ale nie zastępuje wpisu do wykazu podmiotów kluczowych i ważnych, zgłaszania incydentów do CSIRT ani obowiązku audytu bezpieczeństwa.
Ile czasu mam na zgłoszenie poważnego incydentu do CSIRT?
24 godziny na wczesne ostrzeżenie, 72 godziny na pełne zgłoszenie z klasyfikacją i wstępną oceną skutków, a miesiąc od zgłoszenia na sprawozdanie końcowe.
Czy korzystanie z chmury zwalnia mnie z obowiązku zabezpieczenia fizycznego infrastruktury?
NIE. Sama realizacja zabezpieczeń fizycznych przechodzi na dostawcę chmury lub kolokacji, ale odpowiedzialność za wyegzekwowanie tych zabezpieczeń zostaje po stronie Twojej firmy.
Jak zajmujemy się tym w NEXLO
Wdrożeniem SZBI zgodnie z ustawą o KSC zajmuje się w NEXLO Aleksandra Zaniewska, ekspertka ds. compliance z ponad 20-letnim doświadczeniem budowanym in-house w Comarchu, gdzie jako Head of Compliance, Legal & ESG nadzorowała funkcje kontrolne i audyt wewnętrzny. Posiada certyfikaty Approved Compliance Expert, Approved Whistleblowing Officer, Approved AML & Sanctions Officer oraz Approved AI Officer.
Największy błąd, jaki widzimy przy wdrożeniach: firmy zaczynają od kupowania narzędzi technicznych, zanim przeprowadzą analizę ryzyka. Efekt to drogie systemy, które nie odpowiadają na realne zagrożenia i tak czy inaczej brakująca dokumentacja, o którą zapyta audytor.
Nie wiesz, od którego z obowiązków zacząć wdrożenie w swojej firmie? Umów bezpłatną, 45-minutową konsultację. Wspólnie ułożymy plan wdrożenia dopasowany do tego, co już masz, a czego jeszcze brakuje.





