16 października Pełnomocnik Rządu do Spraw Cyberbezpieczeństwa opublikował rekomendację „dotyczącą środków organizacyjnych i technicznych służących zwiększaniu poziomu bezpieczeństwa systemów informacyjnych podmiotów krajowego systemu cyberbezpieczeństwa”. Jako podstawę wskazuje art. 67a ustawy o krajowym systemie cyberbezpieczeństwa. Dokument liczy osiem stron i nie nakłada nowych obowiązków. Mimo to kierownik urzędu powinien go znać. Opisuje, czego administracja rządowa oczekuje od podmiotów KSC, i porządkuje to w układzie, według którego da się zaplanować pieniądze, ludzi i terminy. Jest drogowskazem zwłaszcza dla jednostek, które nie mają wsparcia specjalistów.

Co to za dokument i czym nie jest
Rekomendacja sama określa się jako katalog pomocniczy. Nie zastępuje obowiązków ustawowych ani własnej analizy ryzyka. W zakończeniu zapisano, że środki trzeba dobierać proporcjonalnie: do rodzaju działalności, wagi świadczonych usług, wielkości podmiotu oraz prawdopodobieństwa i skutków incydentu. Dokument nie wymienia z nazwy jednostek samorządu terytorialnego, tylko ogólnie podmioty krajowego systemu cyberbezpieczeństwa.
Dla urzędu ma to znaczenie praktyczne. Ustawa o KSC (Dz.U. z 2026 r. poz. 20 ze zm.) obejmuje podmioty publiczne. Podmiot ważny będący podmiotem publicznym ma według art. 8 ust. 3 wdrożyć i utrzymywać system zarządzania bezpieczeństwem informacji spełniający wymogi załącznika nr 4. Rekomendacja nie zmienia tego obowiązku. Daje za to listę rzeczy, o które kontrolujący najpewniej zapyta. Według harmonogramu Ministerstwa Cyfryzacji termin na pełne wdrożenie mija 3 kwietnia 2027 r., więc realne decyzje finansowe trzeba podjąć w budżecie, który powstaje teraz.
Większość urzędów ma informatyków, którzy wdrażają SZBI i uzupełnili wpis w wykazie podmiotów kluczowych i ważnych. W szkołach, przedszkolach, żłobkach, ośrodkach pomocy społecznej i bibliotekach sytuacja jest znacznie trudniejsza. Brakuje tam fachowców, którzy mogliby skutecznie realizować wymagania z załącznika nr 4 do ustawy o KSC. Te jednostki również są w systemie. Art. 5 ust. 2 pkt 8 zalicza do podmiotów ważnych gminne jednostki budżetowe, zakłady budżetowe i instytucje kultury, jeżeli realizują zadanie publiczne z wykorzystaniem systemów informacyjnych.
Dlaczego kierownika dotyczy to osobiście
Znowelizowana ustawa wprost przenosi odpowiedzialność na kierownika podmiotu. Art. 8c ust. 1 stanowi, że kierownik podmiotu kluczowego lub ważnego odpowiada za wykonywanie obowiązków z zakresu cyberbezpieczeństwa. Ust. 3 dodaje, że odpowiada także wtedy, gdy część zadań powierzył innej osobie. Art. 8d wymienia zadania kierownika: decyzje o przygotowaniu, wdrożeniu, przeglądzie i nadzorze systemu, planowanie środków finansowych, przydział zadań. Art. 8e ust. 1 wymaga, aby kierownik i osoba, której powierzył obowiązki, raz w roku kalendarzowym przechodzili szkolenie, a udział trzeba udokumentować.
Rekomendacja przekłada to na konkret. W punkcie 1.3 wymaga formalnego przypisania odpowiedzialności, macierzy RACI, corocznego szkolenia kierownika i okresowego raportowania kierownictwu poziomu ryzyka oraz stanu zgodności z ustawą. W rozdziale 8 wraca do raportów i dodaje wymóg wyznaczenia co najmniej dwóch osób kontaktowych.
Ustawa przewiduje kary pieniężne także dla kierownika. Według Prawo.pl dla kierownika podmiotu publicznego mogą one sięgnąć 100% wynagrodzenia i będą nakładane od 2028 r.
Kierownictwo urzędów i jednostek organizacyjnych jest zajęte zadaniami, które widzą mieszkańcy, rodzice i uczniowie. Cyberbezpieczeństwa nie widać dopóki coś nie przestanie działać. Czasu na szkolenia jest niewiele, dlatego w mojej opinii trzeba zacząć od uświadomienia, jak ważnym obszarem staje się cyberbezpieczeństwo i odporność infrastruktury IT, OT i IoT na ataki. Ochrony wymaga każdy z tych obszarów i o żadnym nie wolno zapominać: serwer z systemem dziedzinowym, sterownik w stacji uzdatniania wody i kamera monitoringu miejskiego są jednakowo częścią usług publicznych. Bez systemów teleinformatycznych usługi w JST nie działają.
Osiem rozdziałów oczami kierownika
Informatyk przeczyta dokument jako listę zadań technicznych. Kierownik powinien w każdym rozdziale szukać decyzji, których nikt poza nim nie podejmie.
Ryzyko i polityki (rozdz. 1). Analiza ryzyka co najmniej raz w roku i po każdej istotnej zmianie. Do tego zestaw dokumentów: od polityki bezpieczeństwa informacji po ciągłość działania. Decyzja kierownika: kto prowadzi analizę i kiedy wyniki trafiają na jego biurko.
Zasoby, tożsamość, dostęp (rozdz. 2). Rejestr wszystkich zasobów z przypisanym właścicielem, w tym systemów OT i usług wystawionych do internetu. Urządzenia IoT, takie jak kamery czy czujniki, warto dopisać do rejestru z tego samego powodu. Uwierzytelnianie wieloskładnikowe ma być obowiązkowe dla dostępu zdalnego, poczty, systemów krytycznych i kont uprzywilejowanych, a bezpośredni dostęp administracyjny z internetu zablokowany. Dla wielu urzędów samo MFA na poczcie oznacza zakup licencji i zmianę przyzwyczajeń pracowników. Wymaga to decyzji kierownika, nie tylko informatyka.
Cykl życia systemów i podatności (rozdz. 3). Wymagania bezpieczeństwa od etapu zakupu, procedura dla sprzętu i oprogramowania bez wsparcia producenta, formalny proces zarządzania podatnościami. Rekomendacja wskazuje skanowanie bezpłatnym narzędziem Artemis, dostępnym przez moje.cert.pl. Kilka dni później pojawił się praktyczny przykład. 22 października Pełnomocnik zalecił natychmiastową aktualizację PHP, a Centralny Ośrodek Informatyki wyłączył strony BIP działające na platformie SSDIP. Urząd, który ma rejestr usług z PHP i wie, kto za nie odpowiada, w takiej sytuacji działa w ciągu godzin. Urząd bez rejestru najpierw ustala, co w ogóle posiada.
Obawiam się, że informacje o podatnościach, takich jak ostatnie CVE-2026-109618 i CVE-2026-109619, docierają do administratorów systemów informatycznych (ASI) zbyt późno. Administratorzy zajmują się bieżącymi problemami technicznymi i zwykle mają mało czasu na śledzenie nowości. Dobrym rozwiązaniem jest rejestracja w moje.cert.pl, bo zarejestrowane podmioty dostają ostrzeżenia CERT Polska na skrzynkę e-mail. Komunikat o krytycznych lukach w PHP przyszedł 21 października, jeszcze przed wydaniem poprawki. Zawierał zalecenie, aby zinwentaryzować usługi korzystające z PHP i czasowo wyłączyć te dostępne z internetu.
Kopie zapasowe i odtwarzanie (rozdz. 4). Zasada 3-2-1, kopia offline lub poza siedzibą, oddzielenie środowiska kopii od produkcyjnego, ochrona przed zaszyfrowaniem. Dalej regularne i udokumentowane testy odtwarzania, plany BCP i DRP oraz określone wartości RTO i RPO. Ustalenie, jak długo urząd może nie wydawać decyzji czy nie prowadzić ewidencji, jest decyzją zarządczą, a nie techniczną.
Dostawcy (rozdz. 5). Ocena ryzyka dostawcy przed wyborem i okresowo w trakcie umowy. Wymagania bezpieczeństwa, SLA i prawo audytu w umowach. Kontrola zakresu dostępu dostawcy i unikanie koncentracji usług u jednego podmiotu. W zamówieniach publicznych dokument odsyła do podstaw odrzucenia oferty z art. 226 ust. 1 pkt 16, 17 i 19 Prawa zamówień publicznych. Dotyczą one zagrożenia dla bezpieczeństwa publicznego, produktów ICT wskazanych w rekomendacji oraz dostawców wysokiego ryzyka. Według tekstu Ministerstwa Cyfryzacji z serii „Od wymagań do działania” najczęstszym błędem jest przekonanie, że odpowiedzialność za bezpieczeństwo przechodzi na dostawcę razem z umową.
Monitorowanie i incydenty (rozdz. 6). Centralizacja i ochrona logów, SIEM lub rozwiązanie równoważne, monitoring całodobowy tam, gdzie uzasadnia to ryzyko. Do tego procedury obsługi incydentów i zgłaszanie do CSIRT. Przypis zaznacza, że obowiązek raportowania przez system S46 zaczyna się 3 kwietnia 2027 r.
Po realizacji projektu „Cyberbezpieczny Samorząd” wiele urzędów i jednostek wdrożyło system klasy SIEM. Pozostaje pytanie, czy ASI ma czas przeglądać i analizować logi. Dodatkowym problemem jest utrzymanie tych systemów: aktualizacje i wsparcie w kolejnych latach są bardzo kosztowne. Monitoringu całodobowego mała gmina nie zbuduje sama. Tu pojawia się rola usług współdzielonych, na przykład Lokalnych Centrów Cyberbezpieczeństwa, na które nabór trwa do 30 listopada 2026 r.
Świadomość pracowników (rozdz. 7). Szkolenia dopasowane do ról, ćwiczenia i kampanie phishingowe, zasady dla urządzeń prywatnych.
Nadzór i audyt (rozdz. 8). Audyty okresowe, śledzenie wdrożenia zaleceń, analiza przyczyn incydentów, raporty dla kierownictwa.
Czego dokument nie rozstrzyga
Rekomendacja nie mówi, jak pogodzić jej katalog z wymaganiami Krajowych Ram Interoperacyjności, które urzędy powinny stosować od lat. Nie podaje terminów poza cyklem rocznym dla analizy ryzyka i szkoleń. Nie wskazuje też minimalnego poziomu dla małych jednostek. Zasada proporcjonalności daje swobodę, ale przenosi na jednostkę ciężar uzasadnienia, dlaczego dany środek pominięto. Takie uzasadnienie powinno wynikać z udokumentowanej analizy ryzyka, a nie z braku budżetu.
Rekomendacje dla kierownictwa JST
- Do końca listopada zlecić porównanie stanu urzędu i jednostek organizacyjnych z ośmioma rozdziałami rekomendacji. Wynikiem ma być lista luk z szacunkiem kosztu i terminu.
- Na tej podstawie zapisać w budżecie na 2027 r. środki na MFA, kopie offline z testami odtwarzania, monitoring i szkolenia. Termin 3 kwietnia 2027 r. przypada na początek drugiego kwartału, więc środki muszą być dostępne od pierwszych tygodni roku budżetowego.
- Wydać zarządzenie przypisujące role i odpowiedzialności (macierz RACI), wyznaczyć co najmniej dwie osoby kontaktowe i ustalić stały rytm raportów dla kierownika.
- Zaplanować i udokumentować własne szkolenie, zgodnie z art. 8e.
- Przejrzeć umowy z dostawcami IT, w szczególności BIP, hostingu, systemów dziedzinowych i serwisu sprzętu. Sprawdzić zapisy o aktualizacjach, zgłaszaniu incydentów, dostępie zdalnym i prawie audytu.
- Zarejestrować urząd i jednostki organizacyjne w moje.cert.pl, uruchomić skanowanie Artemisem i ustalić, kto i w jakim terminie reaguje na ostrzeżenia i wyniki skanów.
- Uzgodnić z sąsiednimi JST, czy wspólne Lokalne Centrum Cyberbezpieczeństwa może przejąć monitoring i reagowanie dla urzędów, szkół i ośrodków pomocy społecznej, zanim każda jednostka zacznie budować je sama.
Źródła
- Pełnomocnik Rządu (gov.pl); Rekomendacja nr 2026-67a-9, PDF
- Baza wiedzy MC (gov.pl); Rekomendacja Pełnomocnika… dot. środków organizacyjnych i technicznych
- Ministerstwo Cyfryzacji (gov.pl); Rekomendacje Pełnomocnika Rządu ds. Cyberbezpieczeństwa (wykaz)
- Baza wiedzy MC (gov.pl); Rekomendacja Pełnomocnika dotycząca oprogramowania PHP
- Ministerstwo Cyfryzacji (gov.pl); Ważny komunikat: luki w oprogramowaniu PHP
- CERT Polska (moje.cert.pl); ostrzeżenie e-mail nr 195/2026 z 21.10.2026 „Krytyczne podatności w PHP umożliwiające zdalne wykonanie kodu” (zrzut przekazany przez autora)
- CERT Polska (cert.pl); Nowości od CERT Polska: premiera wiedza.cert.pl i nowa funkcja w moje.cert.pl
- Baza wiedzy MC (gov.pl); Od wymagań do działania: Cyberbezpieczeństwo dostawców i usług zewnętrznych
- Samorzad.gov.pl (samorzad.gov.pl); Nowelizacja ustawy o KSC: najważniejsze terminy
- Prawo.pl (prawo.pl); Nowelizacja KSC i NIS 2. Wójt odpowie finansowo za cyberbezpieczeństwo urzędu
- CPPC (gov.pl); Działanie 4.1, trzeci nabór (LCC)
