Przejdź do treści
Filar I / Ład dokumentacyjny25.05.2026 · 7 min

Plan wdrożenia cyberbezpieczeństwa w JST na 30–60–90 dni

Praktyczna mapa drogowa dla urzędu, który chce uporządkować bezpieczeństwo bez wielkiego projektu, certyfikacji i udawania, że ma własny zespół SOC.

Plan wdrożenia cyberbezpieczeństwa w JST na 30–60–90 dni

Cyberbezpieczeństwo w JST nie musi zaczynać się od kosztownego systemu, audytu za kilkadziesiąt tysięcy złotych albo rozbudowanego projektu konsultingowego. W wielu jednostkach rozsądniejszy pierwszy krok jest prostszy: uporządkować to, co już istnieje, wskazać odpowiedzialności i przygotować dokumentację, która będzie działać w praktyce.

Największym ryzykiem dla urzędu często nie jest brak najnowszej technologii. Większym problemem jest brak wiedzy: jakie systemy są krytyczne, kto ma do nich dostęp, kto podejmuje decyzję przy incydencie i jak urząd ma wrócić do pracy po awarii.

Dlatego plan 30–60–90 dni nie jest „poradnikiem o wszystkim”. To mapa wdrożenia. Pokazuje kolejność działań, które można wykonać etapowo: najpierw fundamenty, potem reakcja na incydent, a na końcu odporność organizacyjna.

Dlaczego warto myśleć etapami

Mała lub średnia JST rzadko ma komfort prowadzenia dużego programu cyberbezpieczeństwa. Informatyk obsługuje wiele spraw jednocześnie, kierownictwo potrzebuje prostych argumentów, a dokumentacja często jest rozproszona albo nieaktualna.

Podejście etapowe rozwiązuje ten problem. Nie wymaga budowania wszystkiego naraz. W pierwszych 30 dniach jednostka porządkuje minimum. W kolejnych 30 dniach przygotowuje się do obsługi incydentów. W ostatnim etapie sprawdza, czy urząd jest w stanie utrzymać pracę po awarii, ataku lub utracie dostępności systemów.

W SamorządIT ta logika odpowiada trzem filarom systemu: Filar I obejmuje ład i nadzór, Filar II wykrywanie i reakcję, a Filar III zabezpieczenia operacyjne i odporność  .

Dni 1–30: uporządkowanie podstaw

Pierwszy miesiąc nie powinien zaczynać się od zakupu narzędzi. Powinien zaczynać się od odpowiedzi na proste pytania: co mamy, kto za to odpowiada i które usługi są krytyczne dla pracy jednostki.

Na tym etapie urząd powinien uporządkować rejestr systemów, podstawowe zasady dostępu, standard stacji i serwerów, konta administracyjne oraz minimalne wymagania wynikające z KRI. To jest fundament, bez którego dalsze działania będą improwizacją.

Praktyczny cel po 30 dniach: jednostka wie, jakie systemy posiada, które z nich są najważniejsze, kto ma dostęp administracyjny i jakie podstawowe procedury powinny być aktualne.

W systemie SamorządIT naturalnym punktem startowym jest M05 — Podstawy KRI. Ten moduł obejmuje bazowe polityki, aktywa IT, dostęp, backup, pracę zdalną i rejestr systemów  . W praktyce warto połączyć go z M01 — Minimalny standard stacji i serwera oraz M02 — Konta uprzywilejowane i techniczne, ponieważ sama polityka bez standardu technicznego i kontroli kont administracyjnych nie zamyka podstawowego ryzyka.

Najważniejsze działania w tym etapie:

  1. Spisać systemy i usługi krytyczne, takie jak system finansowo-księgowy, podatki, ePUAP, system obiegu dokumentów, poczta i usługi dziedzinowe.

  2. Wskazać właścicieli systemów i osoby odpowiedzialne za decyzje techniczne.

  3. Zweryfikować konta administracyjne, konta techniczne i dostępy dostawców.

  4. Uporządkować podstawowe procedury KRI.

  5. Sprawdzić, czy backup istnieje nie tylko „w teorii”, ale jest opisany i przypisany do konkretnych systemów.

Ten etap nie ma dawać pełnej dojrzałości. Ma usunąć chaos.

Dni 31–60: przygotowanie do incydentu

Drugi miesiąc powinien odpowiedzieć na pytanie: co robimy, gdy coś się stanie?

W wielu jednostkach problemem nie jest to, że nikt nie chce reagować. Problemem jest to, że nie wiadomo, kto klasyfikuje zdarzenie, kto informuje kierownictwo, kto kontaktuje się z dostawcą, kto zbiera dowody i kto decyduje o odłączeniu systemu od sieci.

W praktyce incydent nie czeka na idealny moment. Może pojawić się jako podejrzany e-mail, zaszyfrowany folder, niedostępny system, nietypowe logowanie albo zgłoszenie od pracownika. Bez procedury każda osoba działa inaczej. To zwiększa ryzyko błędu i utraty dowodów.

Praktyczny cel po 60 dniach: jednostka ma prostą procedurę obsługi incydentu, kartę zdarzenia, rejestr incydentów, podstawową ścieżkę eskalacji i wskazane osoby odpowiedzialne.

W systemie SamorządIT ten etap odpowiada przede wszystkim modułowi M06 — Obsługa incydentów cyberbezpieczeństwa. Moduł obejmuje zgłoszenie, klasyfikację, kartę zdarzenia, rejestr incydentów i playbooki  . Dla jednostek, które chcą uporządkować odpowiedzialności, uzupełnieniem jest M07 — Organizacja zespołu reagowania, czyli RACI, eskalacja, komunikacja kryzysowa i współpraca z dostawcami  .

W tym etapie nie chodzi o stworzenie rozbudowanego centrum operacyjnego. Chodzi o to, żeby przy pierwszych 30 minutach incydentu urząd nie działał na pamięć.

Najważniejsze działania w tym etapie:

  1. Przygotować jedną ścieżkę zgłaszania podejrzanych zdarzeń.

  2. Ustalić, kto klasyfikuje zdarzenie jako incydent.

  3. Wdrożyć kartę incydentu i rejestr incydentów.

  4. Opisać, kiedy informowane jest kierownictwo, IOD, dostawca IT lub zewnętrzne podmioty.

  5. Ustalić podstawowe działania techniczne: izolacja komputera, zabezpieczenie logów, blokada konta, zmiana haseł, kontakt z serwisem.

To jest etap, który daje kierownictwu realną odpowiedź na pytanie: „co zrobimy, gdy urząd zostanie zaatakowany?”.

Dni 61–90: odporność i ciągłość działania

Trzeci miesiąc powinien przenieść uwagę z samej reakcji na pytanie: czy urząd jest w stanie wrócić do pracy?

Backup jest ważny, ale backup nie jest planem ciągłości działania. Sama informacja, że kopia zapasowa „się robi”, nie wystarcza. Jednostka musi wiedzieć, które systemy odtwarza jako pierwsze, ile czasu może nie działać dana usługa, kto podejmuje decyzję o trybie awaryjnym i jak urząd obsłuży mieszkańców, gdy systemy będą niedostępne.

Praktyczny cel po 90 dniach: jednostka ma uporządkowane priorytety usług, podstawowy plan ciągłości działania IT, procedurę odtworzenia i minimalny monitoring zdarzeń.

W systemie SamorządIT kluczowy jest tutaj M10 — Ciągłość działania IT. Moduł obejmuje uproszczoną analizę wpływu na działalność, BCP/DR, priorytety, RPO/RTO, zależności usług i procedury obejściowe  . Dodatkowo warto powiązać go z M14 — Monitoring i wykrywanie zagrożeń, ponieważ monitoring logów i alertów powinien przekazywać sygnały do procesu incydentowego  .

Na tym etapie urząd powinien też zacząć patrzeć na dostawców. Jeżeli system dziedzinowy, poczta, hosting, serwis sprzętu lub kopie zapasowe zależą od zewnętrznej firmy, odpowiedzialność nie znika. Trzeba wiedzieć, kto ma dostęp, na jakich zasadach, w jakim czasie reaguje i jakie są punkty kontaktowe. Do tego służy M11 — Dostawcy i łańcuch dostaw IT.

Najważniejsze działania w tym etapie:

  1. Wskazać systemy, które muszą wrócić jako pierwsze.

  2. Określić minimalne czasy odtworzenia dla usług krytycznych.

  3. Sprawdzić, czy kopie zapasowe da się realnie odtworzyć.

  4. Przygotować procedury obejściowe na czas niedostępności systemów.

  5. Uporządkować kontakty do dostawców i zasady dostępu serwisowego.

  6. Wdrożyć podstawowe monitorowanie zdarzeń, przynajmniej dla krytycznych systemów i kont administracyjnych.

Ten etap zamyka najważniejszą lukę: przejście od „mamy backup” do „wiemy, jak wrócić do działania”.

Co urząd powinien mieć po 90 dniach

Po 90 dniach JST nie musi być organizacją o wysokiej dojrzałości cyberbezpieczeństwa. Nie musi mieć SOC, certyfikacji ani rozbudowanej architektury bezpieczeństwa.

Powinna jednak mieć coś znacznie ważniejszego na tym etapie: uporządkowany punkt startowy.

Po dobrze przeprowadzonym planie 30–60–90 dni jednostka powinna posiadać:

– aktualny rejestr podstawowych systemów i usług,
– opisane odpowiedzialności,
– uporządkowane konta uprzywilejowane,
– podstawowe procedury KRI,
– procedurę obsługi incydentu,
– kartę i rejestr incydentów,
– wskazane osoby do eskalacji,
– plan ciągłości działania IT dla najważniejszych usług,
– przetestowane założenia odtworzenia,
– minimalny monitoring zdarzeń.

To nie jest koniec wdrożenia. To jest koniec improwizacji.

Najczęstszy błąd: zaczynanie od końca

Wiele jednostek próbuje zaczynać od elementów, które wyglądają profesjonalnie, ale nie rozwiązują podstawowego problemu. Kupują narzędzie, zamawiają audyt, wdrażają kolejne zabezpieczenie albo aktualizują pojedynczą politykę. Bez struktury takie działania są punktowe.

Najbardziej ryzykowne skróty to:

– wdrażanie monitoringu bez procedury reakcji,
– tworzenie planu ciągłości bez inwentaryzacji systemów,
– aktualizacja polityki bezpieczeństwa bez kontroli kont uprzywilejowanych,
– opieranie bezpieczeństwa na dostawcy bez kontroli jego dostępów,
– traktowanie backupu jako dowodu odporności.

Poprawna kolejność jest prostsza: najpierw ład i nadzór, potem reakcja, potem odporność. Tę kolejność odzwierciedla architektura SamorządIT: Filar I, Filar II, Filar III  .

Od czego zacząć

Jeżeli jednostka zaczyna od zera, najbezpieczniejszym punktem wejścia jest Filar I. W praktyce oznacza to rozpoczęcie od modułów bazowych: M05 — Podstawy KRI, M01 — Minimalny standard stacji i serwera oraz M02 — Konta uprzywilejowane i techniczne.

Jeżeli urząd ma już podstawową dokumentację, ale nie ma jasnej reakcji na incydent, właściwym kolejnym krokiem będzie M06 — Obsługa incydentów cyberbezpieczeństwa.

Jeżeli największym problemem jest awaria, ransomware, brak testów odtworzenia lub niepewność dotycząca pracy urzędu po utracie systemów, naturalnym kierunkiem będzie M10 — Ciągłość działania IT.

Najważniejsze jest jedno: cyberbezpieczeństwo w JST nie musi zaczynać się od dużego projektu. Może zacząć się od 90-dniowej mapy drogowej, która porządkuje odpowiedzialności, dokumenty i działania operacyjne.