Jak zorganizować projekt wdrożenia KSC w JSFP: sponsor, pakiety prac, budżet i kamienie milowe

Jednostka, która „wdraża KSC”, często miesza trzy różne przedsięwzięcia: wykonanie obowiązków ustawowych, organizację projektu wdrożeniowego oraz zakup lub rozwój narzędzi informatycznych.

W rezultacie powstaje jeden duży projekt „cyberbezpieczeństwo”, w którym obok kwalifikacji podmiotu znajdują się dokumentacja SZBI, wymiana urządzeń sieciowych, dostęp do S46, szkolenia, zakup usług SOC, aktualizacja umów z dostawcami i bieżące zadania administratorów.

Po kilku miesiącach trudno wtedy odpowiedzieć na proste pytanie:

Które obowiązki zostały rzeczywiście wdrożone, które są zagrożone i jakiej decyzji wymaga obecnie projekt od kierownika jednostki?

Lepszym rozwiązaniem jest potraktowanie wdrożenia KSC jako projektu zmiany organizacyjnej: z właścicielem, zakresem, pakietami prac, budżetem, kamieniami milowymi, rejestrem decyzji i jasno zdefiniowanym momentem przejścia do utrzymania.

Kalendarz ustawowy pozostaje wtedy zewnętrznym ograniczeniem projektu — nie zastępuje planu jego realizacji.

Podmiot kluczowy lub ważny ma co do zasady 12 miesięcy od dnia spełnienia przesłanek uznania za taki podmiot na realizację obowiązków rozdziału 3 KSC. W przypadkach, w których status wynika z decyzji przewidzianej ustawą, termin może być liczony od dnia jej doręczenia.

Dla podmiotów, które spełniały przesłanki 3 kwietnia 2026 r., prowadzi to zasadniczo do daty 3 kwietnia 2027 r.

Ten artykuł nie jest kolejnym kalendarzem obowiązków. Pokazuje, jak zorganizować przedsięwzięcie, które ma doprowadzić jednostkę do ich wykonywania.

1. Trzy warstwy, których nie warto mieszać

Na początku trzeba rozdzielić trzy poziomy: prawo, projekt i narzędzie.

KSC nie nakazuje utworzenia formalnego projektu pod nazwą „Wdrożenie KSC” ani zastosowania konkretnej metodyki zarządzania projektami.

Ustawa nakłada natomiast na kierownika odpowiedzialność za wykonywanie obowiązków, wymaga podejmowania decyzji dotyczących SZBI, planowania adekwatnych środków finansowych, przydzielania zadań i nadzorowania ich wykonania.

Projekt jest więc narzędziem zarządczym jednostki, które ma pomóc te obowiązki wdrożyć.

Podobnie zakup aplikacji do zarządzania KSC może znacząco ułatwić pracę, ale zakup systemu informatycznego nie oznacza wdrożenia KSC. System może przechowywać ryzyka, zadania, dokumenty i dowody. Nie podejmie jednak za kierownika decyzji, nie ustanowi rzeczywistych procesów i nie zastąpi działania organizacji.

W zarządzaniu takim przedsięwzięciem można korzystać z klasycznych metodyk projektowych. Przykładowo PM² Komisji Europejskiej przewiduje m.in. kartę projektu, plan prac, raporty statusowe oraz rejestry ryzyk, problemów, decyzji i zmian.

2. Kiedy startować z projektem

Nie warto rozpoczynać pełnego projektu od zamówienia audytu, pisania dokumentacji albo wyboru oprogramowania. Najpierw potrzebna jest wstępna samoidentyfikacja.

Jednostka powinna roboczo ustalić:

• czy może spełniać przesłanki podmiotu kluczowego albo ważnego;
• z jakiego sektora lub rodzaju działalności może wynikać kwalifikacja;
• czy występuje szczególna podstawa dotycząca podmiotu publicznego;
• od jakiej daty mogą być liczone jej terminy;
• jaki model SZBI może mieć zastosowanie.

Nie chodzi jeszcze o przygotowanie pełnego memorandum prawnego. Celem jest odpowiedź: czy istnieją wystarczające przesłanki, aby uruchomić projekt wdrożeniowy?

Ministerstwo Cyfryzacji również wskazuje analizę własnej działalności i ustalenie, czy podmiot spełnia kryteria podmiotu kluczowego lub ważnego, jako jeden z pierwszych kroków dostosowania.

Samoidentyfikacja to nie WP1

Etap przedprojektowy:

wstępna samoidentyfikacja → decyzja o uruchomieniu przedsięwzięcia.

Pierwszy pakiet projektu:

weryfikacja → udokumentowanie → zatwierdzenie kwalifikacji i właściwego modelu obowiązków.

WP1 nie powtarza więc analizy przedprojektowej. Zamienia roboczą hipotezę w udokumentowaną podstawę dalszych działań.

Nie należy też uzależniać rozpoczęcia projektu od samego wpisu do Wykazu KSC.

Wpis do Wykazu KSC nie tworzy statusu podmiotu. Wpis, zmiana wpisu i wykreślenie wpisu są czynnościami materialno-technicznymi i mają charakter deklaratoryjny.

3. Sponsor, kierownik projektu i zespół

Najczęstszym błędem organizacyjnym jest przekazanie całego przedsięwzięcia działowi IT. To za mało. KSC angażuje również kierownictwo, właścicieli procesów, finanse, zamówienia, kadry, bezpieczeństwo informacji i dostawców.

Kierownik jednostki jako sponsor

Art. 8c KSC przypisuje kierownikowi podmiotu kluczowego lub ważnego odpowiedzialność za wykonywanie wskazanych obowiązków cyberbezpieczeństwa. Odpowiedzialność pozostaje przy nim również wtedy, gdy część albo wszystkie obowiązki zostaną powierzone innej osobie.

Art. 8d wymaga od kierownika m.in.:

• podejmowania decyzji dotyczących przygotowania, wdrażania, stosowania, przeglądu i nadzoru SZBI;
• planowania adekwatnych środków finansowych;
• przydzielania zadań z zakresu cyberbezpieczeństwa;
• nadzorowania ich wykonania;
• zapewnienia świadomości personelu.

Dlatego w modelu projektowym naturalnym rozwiązaniem jest przypisanie kierownikowi roli sponsora projektu. Sponsor zatwierdza uruchomienie i zakres projektu, zapewnia zasoby, rozstrzyga konflikty organizacyjne, podejmuje kluczowe decyzje, akceptuje najważniejsze ryzyka i zatwierdza przejście do utrzymania.

„Sponsor projektu” jest jednak rolą zarządczą przyjętą przez jednostkę, a nie funkcją ustanowioną przez KSC.

Kierownik projektu

Kierownikiem projektu może zostać np. osoba odpowiedzialna za bezpieczeństwo informacji, pełnomocnik ds. SZBI, sekretarz, kanclerz albo kierownik właściwej komórki.

Najważniejsza nie jest nazwa stanowiska, lecz możliwość koordynowania działań kilku obszarów organizacji oraz bezpośrednia ścieżka eskalacji do sponsora.

W większej jednostce warto dodatkowo powołać niewielki komitet sterujący obejmujący przedstawicieli kierownictwa, bezpieczeństwa/IT, finansów i zamówień oraz — zależnie od potrzeb — kadr, IOD i właścicieli kluczowych usług. Szczegółowy podział odpowiedzialności warto następnie odwzorować w macierzy RACI.

4. Minimalny zakres projektu

Projekt powinien obejmować przede wszystkim działania konieczne do zorganizowania wykonywania obowiązków właściwych dla konkretnej jednostki.

W minimalnym zakresie warto przewidzieć:

1. kwalifikację podmiotu;
2. ustalenie właściwego modelu SZBI;
3. określenie zakresu systemów i procesów;
4. Wykaz KSC i S46;
5. organizację struktur odpowiedzialnych za cyberbezpieczeństwo;
6. SZBI;
7. analizę ryzyk albo wymagań właściwych dla konkretnego modelu;
8. działania naprawcze;
9. zarządzanie incydentami;
10. ciągłość działania;
11. dostawców i łańcuch dostaw;
12. personel i szkolenia;
13. wymagania dotyczące osób wykonujących zadania z art. 8 lub art. 11;
14. dokumentację i dowody;
15. przygotowanie do audytu — jeżeli obowiązek audytowy ma zastosowanie.

Zakres SZBI zależy od modelu

Nie należy automatycznie zakładać, że objęte KSC jest każde urządzenie i każdy system znajdujący się w jednostce.

W modelu z art. 8 ust. 1 SZBI dotyczy systemów informacyjnych wykorzystywanych w procesach wpływających na świadczenie usługi.

Natomiast podmiot ważny będący podmiotem publicznym, do którego znajduje zastosowanie art. 8 ust. 3, opracowuje i utrzymuje SZBI zgodny z załącznikiem nr 4 w systemach informacyjnych kontrolowanych przez ten podmiot. Dodatkowo art. 16d wiąże wykonywanie określonych obowiązków przez podmiot publiczny z wykorzystywaniem systemu informacyjnego do realizacji zadania publicznego.

Dlatego samo stwierdzenie „jesteśmy jednostką sektora finansów publicznych” nie wystarcza do określenia zakresu projektu.

Czego nie włączać automatycznie do projektu

• działań niezwiązanych z ustaloną podstawą prawną lub rzeczywistymi obowiązkami jednostki;
• modernizacji infrastruktury, które nie wynikają z analizy luk lub ryzyka;
• projektów transformacyjnych prowadzonych „przy okazji KSC”;
• abstrakcyjnego celu „osiągnięcia zgodności z NIS2” bez przełożenia na konkretne wymagania KSC.

Jeżeli jednak analiza wykaże, że brak określonego zabezpieczenia uniemożliwia spełnienie wymagań, konkretna modernizacja może zostać włączona do projektu jako działanie naprawcze.

5. Pakiety prac: podziel projekt na osiem obszarów

Zamiast prowadzić jedną listę kilkuset zadań, lepiej zbudować kilka stabilnych pakietów prac (work packages, WP). Każdy pakiet powinien mieć właściciela, rezultat, termin, zależności, status i wskazane decyzje wymagane od sponsora.

WP4: organizacja cyberbezpieczeństwa

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

Projekt musi więc odpowiedzieć nie tylko „kto prowadzi projekt?”, ale również: kto będzie wykonywał obowiązki po zakończeniu projektu? To dwa różne zagadnienia.

W WP4 należy również uwzględnić wymagania wobec osób realizujących zadania określone w art. 8 lub art. 11. Art. 8f przewiduje wobec tej grupy określone wymagania dotyczące niekaralności. Nie należy więc używać ogólnego hasła „weryfikacja całego personelu”.

6. Kamień milowy to nie termin ustawowy

Termin ustawowy wynika z prawa. Kamień milowy jest wewnętrznym punktem kontrolnym ustalonym przez jednostkę.

Jeżeli jedynym punktem kontrolnym projektu będzie 3 kwietnia 2027 r., informacja o opóźnieniu może pojawić się zbyt późno. Dlatego wewnętrzny termin zakończenia wdrożenia powinien być wcześniejszy niż termin ustawowy i pozostawiać bufor na testy, poprawki, brakujące decyzje i ewentualne problemy zakupowe.

7. Budżet i zasoby w JSFP

Budżet wdrożenia KSC nie jest cennikiem oprogramowania. Art. 8d wymaga od kierownika planowania adekwatnych środków finansowych na realizację obowiązków z zakresu cyberbezpieczeństwa.

Ludzie

Najbardziej niedoszacowanym zasobem jest czas pracowników. Projekt angażuje nie tylko informatyków, ale także kierownictwo, bezpieczeństwo informacji, właścicieli usług, zamówienia, finanse, kadry, obsługę prawną, administratorów systemów i właścicieli umów.

Szkolenia

Trzeba rozdzielić szkolenia kierownictwa wynikające z KSC, szkolenia personelu oraz szkolenia specjalistyczne osób wykonujących konkretne zadania.

Art. 8e wymaga, aby kierownik podmiotu oraz osoba, której powierzono obowiązki kierownika w zakresie cyberbezpieczeństwa, raz w roku kalendarzowym odbywali udokumentowane szkolenie.

Usługi zewnętrzne

W zależności od zidentyfikowanych braków jednostka może potrzebować np. testów bezpieczeństwa, wsparcia przy SZBI, usług monitoringu, obsługi incydentów, audytu albo pomocy przy ciągłości działania.

Technologia

Zakup powinien wynikać z konkretnej potrzeby:

wymaganie → luka → ryzyko → sposób usunięcia lub ograniczenia luki → ewentualny zakup.

Nie odwrotnie.

Wspólna obsługa i CUW

W JST trzeba dodatkowo ustalić, czy część obowiązków będzie wykonywana wspólnie. Art. 16e KSC przewiduje możliwość zapewnienia wspólnej obsługi określonych obowiązków cyberbezpieczeństwa oraz zawierania odpowiednich porozumień między JST.

Nie oznacza to jednak pełnej dowolności w podziale ról. Art. 16f–16h określają część obowiązków jednostki wyznaczonej i podmiotów obsługiwanych. Szczegółowy model współpracy należy więc opisać organizacyjnie z uwzględnieniem podziału obowiązków wynikającego bezpośrednio z ustawy.

8. Najważniejsze ryzyka projektu

Projekt powinien od początku posiadać rejestr ryzyk, problemów i decyzji.

Brak decyzji kierownika

Zespół może przygotować analizę i warianty rozwiązania, ale bez decyzji dotyczącej kwalifikacji, modelu art. 14, budżetu czy właścicieli procesów przedsięwzięcie nie posunie się dalej. Dlatego opóźnienie decyzji sponsora powinno być raportowane tak samo jak opóźnienie zwykłego zadania.

Rozproszenie informacji

Problemem nie jest sam Excel ani używanie kilku narzędzi. Problem powstaje wtedy, gdy organizacja nie potrafi ustalić aktualnego statusu, właściciela zadania, terminu, zależności i dowodu wykonania.

Kopiowanie SZBI z innej jednostki

Dokumentacja przygotowana dla urzędu, szkoły albo dużego podmiotu kluczowego nie musi odpowiadać innej organizacji. SZBI powinien odzwierciedlać rzeczywisty podmiot, systemy i model wynikający z art. 8 KSC.

Mylenie terminów

Termin dotyczący wpisu lub uzupełnienia danych w Wykazie KSC nie jest tym samym co termin wdrożenia obowiązków rozdziału 3. W szczególności 3 października 2026 r. i 3 kwietnia 2027 r. odnoszą się do różnych etapów i nie powinny być stosowane zamiennie.

9. Jak raportować postęp

W projekcie regulacyjnym słabym miernikiem jest komunikat „Jesteśmy zgodni z KSC w 73%”. Taki wynik sugeruje matematyczną precyzję, której zazwyczaj nie ma. Znacznie lepiej raportować status pakietów prac.

Zielony oznacza realizację zgodną z planem, żółty — ryzyko opóźnienia lub potrzebę decyzji, czerwony — zagrożony rezultat lub termin, a szary — pakiet jeszcze nierozpoczęty.

Raport dla kierownika powinien przede wszystkim odpowiadać na pytanie: jakiej decyzji potrzebuje projekt, kto ma ją podjąć i do kiedy?

10. Szablon karty projektu KSC

Karta projektu nie musi być rozbudowanym dokumentem. Jej zadaniem jest jednoznaczne ustalenie, po co realizujemy projekt, kto nim zarządza, czego dotyczy, jakich decyzji wymaga i kiedy można uznać etap wdrożeniowy za zakończony.

Rejestr decyzji

Taki rejestr pozwala odróżnić „zespół nie wykonał zadania” od „zespół nie może kontynuować, ponieważ oczekuje na decyzję kierownika”.

11. Projekt kończy się, obowiązki KSC nie

Projekt wdrożeniowy powinien mieć określony koniec. Cyberbezpieczeństwo — nie.

Dlatego złym kryterium zamknięcia projektu jest „opracowano kompletną dokumentację”. Lepszym:

Jednostka wdrożyła wymagane procesy, sprawdziła ich działanie, przypisała właścicieli i potrafi przedstawić dowody ich wykonywania.

• polityka kopii zapasowych → dowód wykonania i testu odtworzenia;
• procedura aktualizacji → historia wykonanych aktualizacji;
• procedura incydentowa → test lub zapis obsługi rzeczywistego incydentu;
• szkolenie → dokument potwierdzający jego odbycie;
• nadzór nad dostawcą → zapis przeprowadzonego przeglądu.

Przekazanie do utrzymania

Do kalendarza utrzymaniowego należy włączyć także coroczne, udokumentowane szkolenie kierownika oraz osoby, której powierzono obowiązki kierownika w zakresie cyberbezpieczeństwa.

Audyt nie wygląda tak samo dla każdego podmiotu

Ustawowy audyt cykliczny, wykonywany co najmniej raz na trzy lata, dotyczy podmiotów kluczowych.

Podmiot ważny nie podlega temu regularnemu cyklowi, ale organ właściwy może w określonych ustawą okolicznościach nakazać mu przeprowadzenie zewnętrznego audytu.

Jeżeli audyt jest wymagany, jego wykonawca musi zachować ustawowo wymaganą niezależność od realizacji audytowanych zadań. Dlatego WP8 obejmuje koordynację gotowości i audytu, ale nie oznacza, że kierownik projektu sam wykonuje audyt.

Podsumowanie

Wdrożenie KSC w jednostce publicznej nie powinno być prowadzone jako projekt wyłącznie informatyczny, dokumentacyjny ani zakupowy. Jest to projekt zmiany organizacyjnej, w którym technologia jest tylko jednym z elementów.

Dobrze zorganizowane przedsięwzięcie powinno:

1. rozpocząć się od wstępnej samoidentyfikacji;
2. zweryfikować i udokumentować kwalifikację w WP1;
3. posiadać sponsora i operacyjnego kierownika projektu;
4. rozdzielać projekt wdrożeniowy od docelowego modelu realizacji obowiązków z art. 14;
5. zostać podzielone na pakiety prac z mierzalnymi rezultatami;
6. posiadać własne kamienie milowe wcześniejsze niż terminy ustawowe;
7. planować zasoby ludzkie i budżet, a nie tylko zakupy technologiczne;
8. raportować blokady i decyzje zamiast abstrakcyjnego „procentu zgodności”;
9. zakończyć się testem gotowości operacyjnej i formalnym przekazaniem procesów do utrzymania.

Dobrze zaplanowany projekt powinien doprowadzić do sytuacji, w której przed upływem terminu ustawowego jednostka nie „kończy pisać KSC”, lecz normalnie wykonuje obowiązki cyberbezpieczeństwa w swoim codziennym modelu działania.

Zobacz także

• Plan wdrożenia KSC w JSFP do 3 kwietnia 2027 r.
• Czy każda JSFP podlega KSC?
• Kto odpowiada za KSC w jednostce? Macierz RACI+N
• Analiza luk KSC/NIS2

Podstawy prawne i źródła

• Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa — aktualny tekst ujednolicony ↗;
• Ministerstwo Cyfryzacji — najważniejsze terminy nowelizacji KSC ↗;
• Ministerstwo Cyfryzacji — obowiązki podmiotów kluczowych i ważnych ↗;
• System S46 — samorejestracja i wpis do Wykazu KSC ↗;
• Komisja Europejska — PM² Artefacts ↗.

Materiały Ministerstwa Cyfryzacji mają charakter informacyjny i pomocniczy. W przypadku rozbieżności pierwszeństwo mają przepisy ustawy i jej załączników.

Zastrzeżenie: Artykuł ma charakter informacyjny i nie stanowi opinii prawnej ani indywidualnej oceny zgodności konkretnej jednostki. Organizację projektu należy dostosować do statusu podmiotu, sektora, właściwego modelu SZBI, wykorzystywanych systemów i struktury jednostki.