Rejestr decyzji kierownika na potrzeby KSC — co dokumentować i jak go prowadzić

Czym jest rejestr decyzji kierownika

Wdrożenie KSC pozostawia wiele dokumentów: analizę kwalifikacji, dokumentację SZBI, rejestr ryzyka, plany działań, dokumentację incydentów, wyniki audytów czy ustalenia dotyczące wspólnej obsługi. Znacznie łatwiej znaleźć politykę bezpieczeństwa niż po roku odpowiedzieć na pytanie: kto, kiedy, na jakiej podstawie i na jakich warunkach podjął konkretną decyzję zarządczą.

Pomocny może być rejestr decyzji kierownika. Nie jest to kolejny ustawowy rejestr. Ustawa o krajowym systemie cyberbezpieczeństwa nie ustanawia dokumentu o takiej nazwie ani nie określa jego minimalnej zawartości. Jest to narzędzie organizacyjne, które może ułatwić wykazanie, że ważne sprawy zostały przedstawione kierownikowi, rozstrzygnięte, wykonane i później zweryfikowane.

Art. 8d KSC przypisuje kierownikowi m.in. podejmowanie decyzji dotyczących przygotowania, wdrażania, stosowania, przeglądu i nadzoru SZBI, planowanie adekwatnych środków finansowych oraz przydzielanie zadań i nadzór nad ich wykonaniem. Art. 8c ust. 3 przesądza natomiast, że odpowiedzialność kierownika pozostaje również wtedy, gdy obowiązki zostały powierzone innej osobie za jej zgodą.

Rejestr może tworzyć prosty łańcuch:

ustalenie → rekomendacja → decyzja → wykonanie → weryfikacja.

„Decyzja” oznacza w tym artykule wewnętrzne rozstrzygnięcie zarządcze. Karta rejestru nie jest decyzją administracyjną w rozumieniu KPA i nie zastępuje uchwały, zarządzenia, umowy ani innego aktu, dla którego przepisy wymagają określonej kompetencji, formy lub trybu.

Uwaga na okres przejściowy

Nowelizacja KSC weszła w życie 3 kwietnia 2026 r. Podmioty, które w tym dniu spełniały przesłanki uznania za podmiot kluczowy albo ważny, co do zasady mają do 3 kwietnia 2027 r. na wdrożenie obowiązków określonych w rozdziale 3.

Podmioty należące do tej grupy, które nie zostały wpisane do Wykazu KSC z urzędu, składają wniosek o wpis zgodnie z harmonogramem — nie później niż 3 października 2026 r. Podmioty publiczne, przedsiębiorcy telekomunikacyjni, dostawcy usług zaufania i dotychczasowi operatorzy usług kluczowych są wpisywani z urzędu; po otrzymaniu wezwania uzupełniają brakujące dane w terminie sześciu miesięcy od jego doręczenia.

Dla podmiotów kluczowych, które nie były wcześniej operatorami usług kluczowych, termin pierwszego obowiązkowego audytu upływa 3 kwietnia 2028 r. Jeżeli podmiot zacznie spełniać ustawowe przesłanki później, terminy wpisu, wdrożenia obowiązków i pierwszego audytu liczy się od dnia ich spełnienia zgodnie z art. 7c i art. 16 KSC. Przepisy przewidują również przypadki szczególne, w których terminy wiążą się z doręczeniem decyzji o uznaniu podmiotu za kluczowy lub ważny.

Rejestr a dokumentacja z art. 10 KSC

Problem z e-mailem nie polega na jego elektronicznej formie. Powstaje wtedy, gdy w skrzynce znajdują się trzy wersje analizy, uwagi IT, stanowisko prawnika i krótka odpowiedź kierownika: „Akceptuję”. Po kilku miesiącach trudno ustalić, której wersji dotyczyła akceptacja, czy była warunkowa, kto miał wykonać działanie i czy jego wykonanie sprawdzono.

Art. 10 KSC dzieli dokumentację dotyczącą bezpieczeństwa systemu informacyjnego na normatywną i operacyjną. Dokumentacją operacyjną są zapisy poświadczające wykonywanie czynności wymaganych przez dokumentację normatywną.

Nie oznacza to, że każdy dobrowolny rejestr kierownika automatycznie jest dokumentacją operacyjną w rozumieniu art. 10. Jeżeli jednak procedura zarządzania ryzykiem, przeglądu SZBI lub obsługi wyjątków przewiduje określone zatwierdzenia i ich dokumentowanie, karty decyzji mogą stanowić część nadzorowanej dokumentacji SZBI.

Przykładowy wpis:

KD/2026/014: akceptuję ryzyko R-017 na poziomie średnim do 31 marca 2027 r. pod warunkiem wdrożenia zabezpieczeń kompensujących do 15 października 2026 r. Przegląd ryzyka: 15 stycznia 2027 r.

jest bardziej jednoznaczny niż samo „akceptuję”. Nie wystarczy jednak odnotować podpisu. Rejestr nabiera wartości dopiero wtedy, gdy można ustalić także, czy decyzję wykonano i jaki był wynik weryfikacji.

Jakie decyzje warto dokumentować

Rejestr nie powinien być dziennikiem wszystkich czynności technicznych. Warto obejmować nim przede wszystkim rozstrzygnięcia wpływające na zakres SZBI, poziom ryzyka, model organizacyjny, istotne zabezpieczenia, finansowanie albo sposób wykonywania obowiązków.

Nie ma natomiast sensu tworzyć karty kierownika dla resetu hasła, zablokowania konta, zwykłej aktualizacji, codziennej analizy logów czy nadania uprawnienia zgodnie z zatwierdzoną procedurą.

Jeżeli czynność mieści się w zatwierdzonej procedurze i nie zmienia istotnie ryzyka, zakresu SZBI, przyjętych zasad bezpieczeństwa, odpowiedzialności ani zobowiązań organizacji, zwykle nie wymaga osobnej karty decyzji kierownika.

Kwalifikacja: dokumentujemy wynik, a nie „nadajemy status”

Kierownik nie tworzy własnym podpisem statusu podmiotu kluczowego lub ważnego. Status wynika z przesłanek ustawowych. Również wpis do Wykazu KSC ma charakter deklaratoryjny. Art. 7c wiąże termin na złożenie wniosku z dniem spełnienia przesłanek, a art. 7d ust. 5 stanowi, że wpis, jego zmiana i wykreślenie są czynnościami materialno-technicznymi o charakterze deklaratoryjnym.

Dlatego właściwsza sentencja brzmi:

Przyjmuję wynik analizy samoidentyfikacji z dnia 8 września 2026 r., zgodnie z którym jednostka spełnia przesłanki uznania za podmiot ważny, i zatwierdzam działania dostosowawcze wskazane w planie KSC-01.

Nie: „Uznaję jednostkę za podmiot ważny”.

Wewnętrzny przegląd kwalifikacji warto przeprowadzać okresowo oraz po zmianie działalności, wielkości podmiotu, struktury organizacyjnej lub innych istotnych przesłanek. Coroczny przegląd jest rekomendacją organizacyjną, a nie terminem ustawowym. Niezależnie od niego zmianę danych objętych wpisem należy zgłosić w terminie określonym w art. 7c ust. 3 KSC — co do zasady w ciągu 14 dni od zmiany.

Ryzyko: nie myl akceptacji ryzyka z akceptacją niezgodności

Rejestr szczególnie dobrze nadaje się do dokumentowania ryzyka rezydualnego i czasowych wyjątków. Karta nie może jednak służyć do uchylania przepisów. Kierownik może podejmować rozstrzygnięcia dotyczące ryzyka w granicach prawa, przyjętej metodyki i ustalonych kompetencji, ale nie może „zaakceptować” niewykonywania bezwzględnego obowiązku KSC.

Przy wyjątku należy wskazać jego zakres, przyczynę, poziom ryzyka, zabezpieczenia kompensujące, termin ich wdrożenia, właściciela ryzyka, wykonawcę oraz datę wygaśnięcia wyjątku. Jeżeli wymagania prawne albo wiążące decyzje organu nie pozwalają na odstępstwo, karta nie może go zalegalizować.

Art. 14 i wspólna obsługa to nie to samo

Art. 14 przewiduje, że podmiot kluczowy albo ważny w celu realizacji zadań określonych w art. 8 oraz art. 9–13 powołuje wewnętrzne struktury odpowiedzialne za cyberbezpieczeństwo lub zawiera umowę z dostawcą usług zarządzanych w zakresie cyberbezpieczeństwa.

Odrębny mechanizm dotyczy wspólnego wykonywania obowiązków przez podmioty publiczne. Art. 16e określa kilka wariantów zależnie od rodzaju podmiotu, a w JST pozwala m.in. zapewnić wspólną obsługę przy odpowiednim zastosowaniu przepisów ustrojowych albo zawrzeć porozumienie między jednostkami samorządu terytorialnego.

Karta kierownika nie powinna zatem „ustanawiać CUW”, jeżeli kompetencja do utworzenia modelu wynika z odrębnych przepisów. Może dokumentować wdrożenie i wykonywanie modelu prawidłowo ustanowionego przez właściwy organ. Nie każda jednostka realizująca wspólną obsługę musi też formalnie działać pod nazwą centrum usług wspólnych.

Audyt i finansowanie

Audyt: katalog decyzji zależy od rodzaju podmiotu

Podmiot kluczowy przeprowadza audyt co najmniej raz na trzy lata. Organ właściwy może ponadto nakazać zewnętrzny audyt podmiotowi kluczowemu w każdym czasie, a podmiotowi ważnemu w razie incydentu poważnego lub innego naruszenia ustawy.

W rejestrze można dokumentować uruchomienie audytu, wykonanie decyzji organu i późniejsze działania naprawcze. Nie należy jednak automatycznie zakładać, że osobiste „zatwierdzenie audytora” przez kierownika jest zawsze wymagane. Sposób wyboru zależy również od zasad reprezentacji, zamówień i wewnętrznych kompetencji. Wewnętrznego przeglądu lub oceny zgodności nie należy nazywać audytem ustawowym, jeżeli nie spełnia wymagań dotyczących takiego audytu.

Finansowanie: karta nie zastępuje budżetu

Art. 8d wymaga od kierownika planowania adekwatnych środków finansowych na cyberbezpieczeństwo. Wpis może dokumentować przyjęcie priorytetów inwestycyjnych albo skierowanie zapotrzebowania do projektu planu finansowego. Nie zastępuje jednak uchwały budżetowej, zmiany planu, postępowania zakupowego ani czynności innego organu mającego właściwą kompetencję.

Jak powinna wyglądać karta decyzji

Karta powinna być lekka: odsyłać do analiz i dokumentów źródłowych, a w samym rejestrze utrwalać najważniejsze elementy całego cyklu. Pole, które nie ma zastosowania, warto oznaczyć jako „nie dotyczy” zamiast pozostawiać je puste.

Warto unikać ogólnego „polecam”. Sentencja powinna być wykonawcza, np. „Ustalam wdrożenie wariantu B i zobowiązuję kierownika IT do wykonania zabezpieczeń kompensujących do 15 października 2026 r.”

W miarę możliwości wykonania nie powinna weryfikować wyłącznie ta sama osoba, która realizowała działanie. Zakres niezależności weryfikacji należy dostosować do znaczenia decyzji, poziomu ryzyka i wielkości organizacji.

Kto może podpisać kartę

Art. 8c ust. 3 nie jest samodzielną podstawą do delegowania dowolnej kompetencji kierownika. Odnosi się do sytuacji, w której obowiązki zostały już powierzone innej osobie za jej zgodą, i określa skutek: odpowiedzialność kierownika nadal pozostaje.

Dopuszczalność, zakres i sposób działania innej osoby trzeba oceniać na podstawie przepisów właściwych dla konkretnego podmiotu, zasad reprezentacji oraz regulacji wewnętrznych. Jeżeli kartę podpisuje inna osoba, należy wskazać podstawę i zakres powierzenia oraz zweryfikować, czy dana kompetencja może zostać jej powierzona.

Starych kart nie należy nadpisywać. Zmianę można udokumentować wpisem: KD/2027/003 zastępuje KD/2026/014.

Obieg i powiązania z innymi rejestrami

Praktyczny obieg powinien kończyć się później niż w momencie podpisania:

wniosek → opinie → rekomendacja → decyzja → wykonanie → dowód → weryfikacja → przegląd.

IT może przedstawić wykonalność techniczną, osoba odpowiedzialna za cyberbezpieczeństwo — poziom ryzyka, finanse — skutki kosztowe, a prawnik — ograniczenia prawne. IOD powinien uczestniczyć, gdy sprawa dotyczy jego kompetencji w zakresie ochrony danych, ale nie powinien automatycznie zatwierdzać wszystkich decyzji dotyczących cyberbezpieczeństwa.

Jednej decyzji nie trzeba przepisywać do kilku systemów. Jeżeli ryzyko R-017 zaakceptowano kartą KD/2026/014, rejestr ryzyk powinien odsyłać do tej karty, a karta — do R-017 i odpowiedniego planu postępowania. Późniejszy przegląd powinien wskazać, czy warunki decyzji zostały spełnione i czy ryzyko nadal jest akceptowalne.

Przykłady kart decyzji

Przykład 1. Wynik kwalifikacji KSC

Nr: KD/2026/001
Przedmiot: przyjęcie wyniku analizy kwalifikacji KSC.
Materiały: analiza KSC-KW-01 z 8 września 2026 r.

Sentencja:

Przyjmuję wynik analizy kwalifikacji z dnia 8 września 2026 r., zgodnie z którym jednostka spełnia przesłanki uznania za podmiot ważny będący podmiotem publicznym. Zatwierdzam realizację działań wynikających z planu KSC-01.

Właściciel monitorowania kwalifikacji: pełnomocnik ds. cyberbezpieczeństwa.
Przegląd: wewnętrznie co najmniej raz w roku oraz po zmianie działalności, wielkości podmiotu, struktury organizacyjnej albo innych przesłanek mogących wpłynąć na kwalifikację.
Adnotacja: karta dokumentuje wynik samoidentyfikacji i podjęte działania. Nie nadaje podmiotowi statusu podmiotu ważnego.

Przykład 2. Akceptacja ryzyka rezydualnego

Nr: KD/2026/018
Przedmiot: czasowa akceptacja ryzyka R-027.
Stan: docelowa segmentacja sieci wymaga przebudowy komponentu i nie może zostać wykonana natychmiast.

Sentencja:

Akceptuję ryzyko rezydualne R-027 na poziomie średnim do 31 marca 2027 r. pod warunkiem wdrożenia zabezpieczeń kompensujących określonych w PR-027 do 15 października 2026 r. oraz wykonania docelowej segmentacji do 31 marca 2027 r. Decyzja podlega wcześniejszemu przeglądowi w przypadku wzrostu ryzyka, istotnej zmiany środowiska lub incydentu związanego z tym ryzykiem.

Właściciel ryzyka: członek kierownictwa odpowiedzialny za proces korzystający z systemu.
Wykonawca planu: kierownik IT.
Dowód wykonania zabezpieczeń: raport zmian i wynik testu.
Weryfikacja: osoba odpowiedzialna za cyberbezpieczeństwo, do 22 października 2026 r.
Przegląd: 15 stycznia 2027 r.

Przykład 3. Wdrożenie wspólnej obsługi w JST

Karta nie ustanawia wspólnej obsługi. Dokumentuje sposób realizacji modelu ustanowionego przez właściwy organ.

Nr: KD/2026/022
Przedmiot: organizacja wykonywania obowiązków KSC w modelu wspólnej obsługi.
Podstawa: właściwa uchwała, porozumienie albo inny akt, ze wskazaniem konkretnej podstawy — np. art. 16e ust. 5 albo ust. 6 KSC oraz odpowiednich przepisów ustrojowych.

Sentencja:

W związku z objęciem jednostki wspólną obsługą w zakresie obowiązków cyberbezpieczeństwa przyjmuję zasady współpracy z jednostką obsługującą określone w załączniku nr 1 i wskazuję osoby odpowiedzialne po stronie jednostki za terminowe przekazywanie informacji niezbędnych do wykonywania powierzonych obowiązków.

Powiązania: RACI KSC, procedura incydentowa, wykaz kontaktów. Art. 16f przewiduje po stronie obsługiwanych podmiotów m.in. przekazywanie informacji o incydentach oraz wykonywanie decyzji kierownika jednostki wyznaczonej w zakresie SZBI.

Ochrona, wersjonowanie i retencja

Rejestr może zawierać informacje o lukach, ryzykach, wyjątkach, planowanych zabezpieczeniach i terminach usunięcia słabości. Sam może więc stać się wrażliwym zasobem. W głównym rejestrze warto przechowywać tylko informacje niezbędne do odtworzenia procesu decyzyjnego, a szczegóły podatności, topologii sieci czy konfiguracji pozostawiać w kontrolowanych załącznikach.

Jeżeli rejestr stanowi element dokumentacji objętej art. 10 KSC, trzeba zapewnić dostęp wyłącznie osobom upoważnionym, ochronę przed uszkodzeniem, zniszczeniem, utratą, nieuprawnionym dostępem i utratą integralności oraz oznaczanie kolejnych wersji w sposób pozwalający określić dokonane zmiany.

System powinien pozwalać ustalić, kto i kiedy utworzył, zatwierdził lub zmienił wpis. Sama edytowalna tabela bez historii zmian może nie zapewnić wystarczającego śladu audytowego.

Ustawa określa również reguły przechowywania wycofanej dokumentacji oraz protokolarnego brakowania. Reguły retencji z art. 10 ust. 7 nie stosują się jednak do podmiotów podlegających ustawie o narodowym zasobie archiwalnym i archiwach. W takich jednostkach retencję trzeba powiązać z przepisami archiwalnymi, instrukcją kancelaryjną i właściwym wykazem akt.

W przypadku podmiotu publicznego nie należy automatycznie oznaczać całego rejestru jako „niepodlegającego udostępnieniu”. Ewentualne ograniczenie dostępu trzeba oceniać na podstawie treści konkretnej informacji i właściwej podstawy prawnej.

Decyzje kierownika nie mogą blokować zgłoszenia incydentu

Procedura nie może uzależniać terminowego zgłoszenia incydentu od dostępności kierownika, jeśli groziłoby to przekroczeniem terminu ustawowego.

Co do zasady podmiot kluczowy lub ważny przekazuje wczesne ostrzeżenie nie później niż w ciągu 24 godzin od wykrycia incydentu poważnego, a zgłoszenie incydentu — nie później niż w ciągu 72 godzin. Ustawa przewiduje jednak regulacje szczególne dla niektórych kategorii podmiotów.

Dla podmiotu ważnego będącego podmiotem publicznym art. 12c wyłącza obowiązek przekazywania wczesnego ostrzeżenia, sprawozdania okresowego, sprawozdania z postępu obsługi oraz sprawozdania końcowego. Pozostaje obowiązek zgłoszenia incydentu poważnego w ciągu 72 godzin. Przy ustalaniu obowiązującego trybu należy uwzględnić również przepisy przejściowe i przepisy szczególne dotyczące konkretnego podmiotu.

Podsumowanie

Rejestr decyzji kierownika nie jest dokumentem wymaganym przez KSC. Może jednak uporządkować najważniejsze rozstrzygnięcia zarządcze i powiązać je z wykonaniem oraz weryfikacją. Jego wartość nie wynika z liczby kart, lecz z możliwości odtworzenia ciągu:

decyzja → zadanie → dowód wykonania → wynik weryfikacji.

Jeżeli organizacja wpisze „wdrożyć MFA do 30 listopada”, a później niczego nie wdroży, starannie wypełniona karta nie rozwiązuje problemu. Rejestr pomaga wykazać zarządzanie tylko wtedy, gdy pokazuje również rezultat i jego sprawdzenie.

Zobacz także

• Odpowiedzialność kierownika podmiotu kluczowego lub ważnego po nowelizacji KSC
• Kto odpowiada za obowiązki KSC w jednostce? Przykładowa macierz RACI+N
• Zarządzanie ryzykiem cyberbezpieczeństwa w JSFP
• Jak przygotować podmiot do audytu KSC?
• Zgłaszanie incydentów w KSC – terminy, odpowiedzialność i obieg informacji

Źródła

1. Ustawa z 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa, t.j. Dz.U. z 2026 r. poz. 20, ze zm., w szczególności zmianami wynikającymi z Dz.U. z 2026 r. poz. 252 i 815. Ustawa o KSC – tekst jednolity i późniejsze zmiany w ELI ↗
2. Ustawa z 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa oraz niektórych innych ustaw, Dz.U. z 2026 r. poz. 252. Ustawa nowelizująca – ELI ↗
3. Ministerstwo Cyfryzacji – Nowelizacja ustawy o KSC: najważniejsze terminy. Harmonogram Ministerstwa Cyfryzacji ↗
4. Ministerstwo Cyfryzacji – wpisy z urzędu i uzupełnianie danych. Komunikat o wpisach z urzędu ↗
5. Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (NIS2), w szczególności art. 20 dotyczący odpowiedzialności organów zarządzających. Dyrektywa NIS2 w EUR-Lex ↗

Materiały Ministerstwa Cyfryzacji mają charakter informacyjny i pomocniczy. Podstawą ustalania obowiązków konkretnego podmiotu pozostają obowiązujące przepisy prawa.

Artykuł ma charakter informacyjny i nie stanowi opinii prawnej. Zakres obowiązków konkretnej jednostki wymaga uwzględnienia jej statusu, podstawy kwalifikacji, wykonywanej działalności, wykorzystywanych systemów oraz właściwych przepisów szczególnych.