Decyzja nr 172/MON: instrukcja obsługi SZBI, na którą czekało 27 tysięcy urzędów

We wtorek 8 września 2026 roku w Dzienniku Urzędowym Ministra Obrony Narodowej ukazał się dokument, który nie trafił na żaden pierwszy pasek. Decyzja nr 172/MON Ministra Obrony Narodowej w sprawie Systemu Zarządzania Bezpieczeństwem Informacji weszła w życie nazajutrz, 9 września. Kilkanaście stron, paragrafy, punkty, litery, wyliczenia obowiązków dyrektorów departamentów. Lektura, której nikt nie bierze na wakacje.

A jednak jest to jeden z ciekawszych dokumentów, jakie polska administracja wyprodukowała w tym roku — i to nie dlatego, że dotyczy wojska. Dlatego, że resort obrony narodowej, czyli instytucja, która w 2025 roku odnotowała około 7 tysięcy incydentów, o 60 procent więcej niż rok wcześniej, i której wiceminister Cezary Tomczyk mówił publicznie, że jesteśmy w trójce najbardziej atakowanych państw Europy, usiadł i napisał czarno na białym, jak wygląda system zarządzania bezpieczeństwem informacji. Nie czym jest w teorii. Jak wygląda: kto co robi, kto co akceptuje, czyj podpis otwiera system produkcyjny i kto odpowiada za to, że w środę rano nikt nie ma uprawnień, których nie powinien mieć.

Podstawą prawną decyzji nie jest żaden przepis o informacjach niejawnych ani specjalna regulacja wojskowa. Jest nią § 19 rozporządzenia Rady Ministrów z 21 maja 2024 roku w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz.U. 2024 poz. 773). Ten sam paragraf, który wiąże urząd gminy w powiecie kłodzkim, zespół szkół w Katowicach, miejską bibliotekę, zakład wodociągowy i szpital powiatowy. Dokładnie ten sam. Różnica polega wyłącznie na tym, że resort obrony właśnie pokazał, co z niego wynika w praktyce.

Co właściwie podpisał minister

Decyzja nr 172/MON nie ustanawia nowego obowiązku — ona ten obowiązek wykonuje. Rozdziela zadania między kierownictwo ministerstwa, dyrektorów komórek organizacyjnych, Dyrektora Departamentu Cyberbezpieczeństwa, Dyrektora Departamentu Ochrony Informacji Niejawnych, Dyrektora Generalnego oraz Dowódcę Komponentu Wojsk Obrony Cyberprzestrzeni. Każdy z tych podmiotów dostaje wyliczoną listę czynności, a nie deklarację, że „dba o bezpieczeństwo informacji”.

To brzmi banalnie do momentu, w którym porówna się tę konstrukcję z typową dokumentacją, jaką zastajemy w jednostkach publicznych podczas audytu. Standardowy zestaw to Polityka Bezpieczeństwa Informacji z rokiem 2019 w stopce, załącznik z analizą ryzyka wypełniony raz przy okazji projektu dotacyjnego, instrukcja zarządzania systemem teleinformatycznym opisująca serwer, którego już nie ma, i zarządzenie kierownika jednostki powołujące Administratora Systemów Informatycznych — zwykle tę samą osobę, która odbiera telefony o zaciętej drukarce. Formalnie komplet. Funkcjonalnie zbiór plików.

Decyzja MON robi coś, czego ten zbiór plików nie robi nigdy: wiąże czynności z konkretnymi rolami i konkretnymi momentami w czasie. Nie „zapewnia się bezpieczeństwo systemów”, tylko: przed uruchomieniem systemu wydaje się opinię, wyniki szacowania ryzyka przekazuje się określonej osobie, ta osoba je akceptuje, a ktoś inny proponuje na ich podstawie działania naprawcze. To jest różnica między opisem stanu pożądanego a procesem, który da się wykonać, sprawdzić i skontrolować.

Paragraf 19, czyli obowiązek, o którym wszyscy wiedzą i nikt go nie ma

Warto przypomnieć, co dokładnie mówi przepis, na który powołał się minister. Podmiot realizujący zadania publiczne opracowuje, ustanawia, wdraża, eksploatuje, monitoruje, przegląda, utrzymuje i doskonali system zarządzania bezpieczeństwem informacji. Osiem czasowników. Nie „posiada dokumentację” — osiem czasowników opisujących cykl, który się nie kończy.

Rozporządzenie idzie dalej i wskazuje punkt odniesienia. Wymagania uznaje się za spełnione, jeżeli system zarządzania bezpieczeństwem informacji został opracowany na podstawie Polskiej Normy PN-ISO/IEC 27001, a ustanawianie zabezpieczeń, zarządzanie ryzykiem oraz audytowanie odbywa się zgodnie z normami powiązanymi, w tym PN-ISO/IEC 27002 i PN-ISO/IEC 27005. Certyfikat nie jest wymagany — i to jest najczęściej nadużywany fragment całej regulacji. Brak wymogu certyfikacji bywa czytany jako brak wymogu systemu, a to dwie zupełnie inne rzeczy. Norma zostaje wymagana w warstwie merytorycznej; jedyne, czego nie trzeba, to jednostka certyfikująca i audyt trzeciej strony.

Do tego dochodzi § 19 ust. 2 pkt 14, nakazujący zapewnienie okresowego audytu wewnętrznego w zakresie bezpieczeństwa informacji. Okresowego, czyli powtarzalnego, czyli takiego, który generuje ślad w czasie: raport, listę niezgodności, plan działań naprawczych i dowód, że te działania zamknięto. W jednostkach, które obsługujemy, pytanie „proszę pokazać raport z ostatniego audytu bezpieczeństwa informacji i status rekomendacji” rozstrzyga sprawę w trzy minuty. Albo taki raport jest i ktoś potrafi wskazać, co z niego wynikło, albo go nie ma i wszystkie pozostałe pytania przestają mieć znaczenie.

Dwa poziomy ryzyka: sedno decyzji

Najciekawszy fragment decyzji nr 172/MON dotyczy szacowania ryzyka i jest rozwiązaniem, które warto przenieść niemal jeden do jednego. Resort rozdzielił ocenę ryzyka na dwa tory: ogólnosystemowy i lokalny.

Tor ogólnosystemowy prowadzi Dowódca Komponentu Wojsk Obrony Cyberprzestrzeni. To on przedstawia wyniki ogólnosystemowego szacowania ryzyka oraz szacowania ryzyka dla konkretnego systemu informatycznego lub usługi — po to, aby posłużyły do przeprowadzenia szacowania lokalnego w ministerstwie. Innymi słowy: podmiot, który widzi całą infrastrukturę, telemetrię, incydenty i wyniki testów, dostarcza obraz zagrożeń. Nie prosi się o niego każdego kierownika wydziału z osobna.

Tor lokalny prowadzi Dyrektor Departamentu Cyberbezpieczeństwa MON, który przewodniczy pracom i przesyła ich wyniki wraz z planami postępowania z ryzykiem do Dyrektora Generalnego. Dyrektor Generalny odpowiada za akceptację tych wyników. W pracach uczestniczą Dowódca WOC, Dyrektor Departamentu Ochrony Informacji Niejawnych, organizatorzy systemów informatycznych będący kierownikami komórek organizacyjnych oraz sami kierownicy komórek.

Ta konstrukcja rozwiązuje problem, o który rozbija się większość analiz ryzyka w sektorze publicznym. Typowa analiza powstaje w jednym z dwóch skrajnych wariantów: albo pisze ją informatyk, który zna systemy, ale nie zna wartości procesów biznesowych, albo pisze ją osoba od dokumentacji, która zna procesy, ale ocenia podatności z internetu. W obu przypadkach wychodzi arkusz, w którym wszystkie ryzyka mają poziom średni, a plan postępowania sprowadza się do „monitorować”. Rozdzielenie toru technicznego od toru decyzyjnego, z imiennie wskazanym akceptantem na końcu, likwiduje tę patologię — bo ktoś musi się pod wynikiem podpisać, a podpisuje się osoba, która odpowiada za budżet i ciągłość działania jednostki.

Bramka przed uruchomieniem systemu

Drugi element wart skopiowania jest jeszcze prostszy i jeszcze rzadziej spotykany. Zgodnie z § 4 pkt 1 lit. d decyzji, Dyrektor Generalny wyraża zgodę na uruchomienie w ministerstwie systemu teleinformatycznego lub informatycznego oraz wiążących się z nim usług. A zgodnie z § 4 pkt 2 lit. c, przed uruchomieniem Dyrektor Departamentu Cyberbezpieczeństwa wydaje opinię w zakresie zgodności systemu z polityką bezpieczeństwa informacji.

Mamy więc formalną bramkę: nowy system nie wchodzi do eksploatacji bez opinii bezpieczeństwa i bez zgody kierownictwa administracyjnego. Dwa podpisy, dwie różne role, dwa różne punkty widzenia.

Teraz przeniesienie na grunt samorządowy. Ile jednostek publicznych w Polsce potrafi wskazać dokument, w którym ktokolwiek wyraził zgodę na uruchomienie e-usługi, portalu mieszkańca, systemu rezerwacji wizyt, aplikacji do konsultacji społecznych albo modułu płatności? W praktyce system pojawia się tak: wpływa dotacja, ogłasza się postępowanie, wykonawca wdraża, odbiór techniczny podpisuje ktoś z wydziału merytorycznego, a pierwsza rozmowa o bezpieczeństwie odbywa się dwa lata później, gdy w logach pojawia się coś niepokojącego albo gdy kontrola pyta o umowę powierzenia. Bramka z decyzji MON kosztuje jedno zdanie w zarządzeniu kierownika jednostki i jedną kartkę opinii przed startem. Jej brak kosztuje znacznie więcej i zawsze później.

Do bramki dochodzi jeszcze § 4 pkt 7 lit. c: kierownicy komórek organizacyjnych wnioskują o nadanie, zmianę i cofnięcie uprawnień do systemu. To przepis, który w codziennej pracy znaczy więcej niż dziesięć polityk. Uprawnienia nadaje się na wniosek osoby odpowiedzialnej za merytorykę, a nie na telefon do informatyka — i, co ważniejsze, cofa się je tym samym trybem, którym się je nadało. Większość naruszeń ochrony danych, z którymi spotykamy się w jednostkach publicznych, ma swój początek dokładnie tutaj: w koncie pracownika, który zmienił stanowisko trzy lata temu, i w skrzynce, do której nadal ma dostęp firma wdrożeniowa.

Właściciel systemu zamiast informatyka od wszystkiego

Paragraf 4 pkt 6 lit. a decyzji przypisuje organizatorom systemów informatycznych, będącym kierownikami komórek organizacyjnych, odpowiedzialność za zapewnienie bezpieczeństwa systemu informatycznego w całym cyklu życia systemu. Sformułowanie „w całym cyklu życia” nie jest ozdobnikiem. Obejmuje analizę potrzeb, wymagania w postępowaniu, wdrożenie, eksploatację, aktualizacje, migracje i wycofanie z użycia razem z bezpiecznym usunięciem danych.

W polskim sektorze publicznym ta rola jest niemal nieobsadzona. Istnieje Administrator Systemów Informatycznych, istnieje czasem Pełnomocnik do spraw bezpieczeństwa informacji, istnieje Inspektor Ochrony Danych — ale właściciela biznesowego systemu, czyli osoby, która odpowiada za to, po co ten system w ogóle jest i jakie ryzyko akceptuje, zwykle nie ma. Efekt jest przewidywalny: gdy dostawca kończy wsparcie dla wersji, nikt nie podejmuje decyzji o migracji, bo nikt nie czuje się do niej uprawniony. Gdy kończy się umowa serwisowa, przedłuża się ją automatycznie, bo alternatywa wymagałaby właściciela. Gdy trzeba zdecydować, czy wyłączyć moduł z podatnością krytyczną w środku sezonu podatkowego, decyzję podejmuje ten, kto akurat odbierze telefon.

Wskazanie właściciela systemu to jedna z tańszych i najbardziej dotkliwych w skutkach zmian, jakie można przeprowadzić w urzędzie. Tańszych, bo nie wymaga ani złotówki na licencje. Dotkliwych, bo od tego momentu przestaje istnieć wygodna przestrzeń, w której odpowiedzialność rozprasza się między wydziałami.

Pętla korekcyjna, czyli różnica między dokumentem a systemem

Ostatni element decyzji, który zasługuje na uwagę, dotyczy sprzężenia zwrotnego. Dowódca WOC został zobowiązany do przedstawiania propozycji działań korekcyjnych i naprawczych dla SZBI w oparciu o wyniki analizy informacji o stanie zabezpieczeń, wyniki testów bezpieczeństwa, incydenty, podatne zasoby i zagrożenia cyberbezpieczeństwa dotyczące systemów wykorzystywanych w ministerstwie. Oprócz tego projektuje i implementuje zabezpieczenia stosownie do wyników szacowania ryzyka, zapewnia monitorowanie systemów teleinformatycznych resortu obrony narodowej wykorzystywanych w ministerstwie oraz opracowuje i aktualizuje metodykę szacowania ryzyka bezpieczeństwa informacji.

To jest właśnie ta część normy PN-ISO/IEC 27001, która w dokumentacji jednostek publicznych występuje najrzadziej — ciągłe doskonalenie oparte na danych z eksploatacji. Incydent nie kończy się na wpisie do rejestru i zgłoszeniu do CSIRT NASK. Incydent wraca do analizy ryzyka, zmienia ocenę prawdopodobieństwa, wymusza korektę zabezpieczeń i aktualizację samej metodyki. Bez tej pętli SZBI jest zdjęciem zrobionym w dniu podpisania polityki. Z nią staje się systemem w sensie, w jakim rozumie to rozporządzenie: czymś, co się eksploatuje, monitoruje, przegląda, utrzymuje i doskonali.

Sprawdzian jest prosty i każdy kierownik jednostki może go przeprowadzić samodzielnie w pięć minut. Proszę wziąć rejestr incydentów za ostatnie dwanaście miesięcy i analizę ryzyka. Jeżeli w analizie ryzyka nie widać śladu po żadnym z incydentów z rejestru, to nie ma systemu zarządzania. Są dwa dokumenty, które nigdy się nie spotkały.

Trzeci października i zegar, który rusza zaraz potem

Decyzja MON ukazała się w szczególnym momencie kalendarza. Do 3 października 2026 roku podmioty spełniające kryteria z nowelizacji ustawy o krajowym systemie cyberbezpieczeństwa muszą złożyć wniosek o wpis do Wykazu podmiotów kluczowych i podmiotów ważnych. Samorejestracja działa od 7 maja 2026 roku, wyłącznie elektronicznie, w aplikacji dostępnej pod adresem wykaz-ksc.gov.pl, będącej częścią rządowego systemu S46. Wcześniej, między 13 kwietnia a 6 maja, Minister Cyfryzacji wpisał z urzędu wybrane kategorie podmiotów — operatorów usług kluczowych, dostawców usług zaufania, przedsiębiorców telekomunikacyjnych i część podmiotów publicznych.

Skala jest tu istotna. Ministerstwo Cyfryzacji szacuje, że nowe przepisy obejmą około 38 tysięcy podmiotów, z czego blisko 27 tysięcy to podmioty publiczne. Dla porównania, w komunikacie z 7 lipca 2026 roku resort podawał, że z S46 Cyber Hub korzystało wówczas ponad 2 tysiące podmiotów. Różnica między tymi liczbami to dystans, jaki polska administracja ma do pokonania w niecałe trzy tygodnie.

I tu pojawia się rzecz, którą warto powiedzieć wprost: wpis do wykazu nie jest metą, tylko linią startu. Ustawa w brzmieniu obowiązującym od 3 kwietnia 2026 roku nakłada w art. 8 obowiązek wdrożenia systemu zarządzania bezpieczeństwem informacji obejmującego czternaście obszarów środków technicznych i organizacyjnych — od polityki analizy ryzyka i bezpieczeństwa systemów informacyjnych, przez bezpieczeństwo łańcucha dostaw, ciągłość działania, obsługę incydentów, monitorowanie i ocenę skuteczności, edukację i cyberhigienę, kryptografię, bezpieczną komunikację, aż po zarządzanie aktywami i kontrolę dostępu. Środki mają być odpowiednie i proporcjonalne do oszacowanego ryzyka, z uwzględnieniem stanu wiedzy, kosztów wdrożenia, wielkości podmiotu, prawdopodobieństwa wystąpienia incydentów oraz ich skutków społecznych i gospodarczych.

Terminy przejściowe są znane. Podmioty, które istniały w dniu wejścia ustawy w życie, mają dwanaście miesięcy na wdrożenie obowiązków związanych z systemem zarządzania bezpieczeństwem informacji, czyli czas do 3 kwietnia 2027 roku. Podmioty kluczowe mają dwadzieścia cztery miesiące na przeprowadzenie pierwszego audytu bezpieczeństwa systemu informacyjnego, a więc do 3 kwietnia 2028 roku. Kary sięgają dziesiątek milionów złotych, a nowelizacja przewiduje również odpowiedzialność osób kierujących podmiotem. Kto zarejestruje się 2 października i uzna sprawę za zamkniętą, obudzi się na początku 2027 roku z sześcioma miesiącami na zbudowanie czternastu obszarów od zera.

Nowa Ruda, Tczew i cena braku SZBI

Żeby ten wywód nie pozostał na poziomie paragrafów, dwa przykłady z tego roku — oba z sektora, który zna każdy czytelnik.

23 czerwca 2026 roku Urząd Miejski w Nowej Rudzie padł ofiarą ataku ransomware. Zaszyfrowana została część danych na komputerach pracowników, a incydent objął również środowisko wirtualizacyjne obsługujące systemy informatyczne urzędu. W zawiadomieniu gmina przyznała, że nie można wykluczyć nieuprawnionego dostępu do danych na serwerach, a katalog zagrożonych kategorii obejmował imiona i nazwiska, adresy, daty i miejsca urodzenia, numery PESEL, serie i numery dowodów osobistych, numery telefonów, adresy e-mail oraz imiona rodziców. Sprawę zgłoszono do CSIRT NASK, Policji i Urzędu Ochrony Danych Osobowych. Nowa Ruda była czwartym miastem lub gminą zaatakowanym w pierwszej połowie 2026 roku, po Obrazowie w lutym, Myszkowie w marcu i Lewinie Kłodzkim w maju.

Drugi przykład jest cichszy i przez to bardziej pouczający. 1 kwietnia 2026 roku Centrum Administracyjne Placówek Opiekuńczo-Wychowawczych w Tczewie stwierdziło nieuprawnione wykorzystanie dwóch służbowych adresów e-mail do rozsyłania spamu. Analiza logów potwierdziła przejęcie kont przez osoby trzecie. Placówka, nie mogąc wykluczyć wycieku, przyjęła wariant najwyższego ryzyka i założyła, że przejęte zostały dane gromadzone na serwerach pocztowych od 2018 roku, w tym Karty Dziecka z lat 2018–2026, opisy sytuacji rodzinnej i zdrowotnej, oceny rozwoju podopiecznych, informacje dla sądów oraz opinie dotyczące adopcji i pieczy zastępczej.

W obu przypadkach nie zawiodła żadna egzotyczna technologia. Zawiodły rzeczy, które decyzja nr 172/MON opisuje dosłownie: nadzór nad uprawnieniami, monitorowanie systemów, pętla korekcyjna łącząca incydenty z oceną ryzyka i imiennie przypisana odpowiedzialność za system w całym cyklu jego życia. Dwuskładnikowe uwierzytelnianie na skrzynkach służbowych jest darmowe. Kosztowna jest wyłącznie decyzja, żeby je włączyć, i osoba, która tę decyzję podejmie.

Co z decyzji MON przenosi się do urzędu, a co nie

Nie wszystko. Struktura resortu obrony narodowej jest nieporównywalna z gminą liczącą dwudziestu pięciu pracowników, a Komponent Wojsk Obrony Cyberprzestrzeni nie ma odpowiednika w starostwie powiatowym. Przenoszenie decyzji jeden do jednego byłoby dokładnie tym błędem, który krytykujemy w dokumentacji tworzonej z szablonów: dużo paragrafów, zero wykonalności.

Przenosi się natomiast logika, i to bez strat. Po pierwsze, rozdzielenie szacowania ryzyka na warstwę techniczną, dostarczaną przez tego, kto widzi infrastrukturę i incydenty, oraz warstwę decyzyjną, w której ryzyko akceptuje imiennie wskazany członek kierownictwa. W gminie rolę pierwszą pełni informatyk lub dostawca usług IT, rolę drugą sekretarz albo skarbnik — i to wystarczy, o ile zostanie zapisane. Po drugie, bramka przed uruchomieniem systemu: żadna nowa e-usługa nie startuje bez pisemnej opinii bezpieczeństwa i zgody kierownika jednostki. Po trzecie, właściciel systemu wskazany z imienia i nazwiska dla każdej pozycji w ewidencji systemów. Po czwarte, wnioskowy tryb nadawania, zmiany i cofania uprawnień, prowadzony przez kierowników komórek. Po piąte, obowiązek przedstawiania propozycji działań naprawczych po każdym incydencie i po każdym teście bezpieczeństwa.

Pięć mechanizmów, żaden nie wymaga zakupu oprogramowania, wszystkie mieszczą się w jednym zarządzeniu kierownika jednostki i w czterech załącznikach. Różnica między jednostką, która je ma, a jednostką, która ich nie ma, ujawnia się nie podczas kontroli, tylko trzeciego dnia po ataku — gdy trzeba ustalić, kto ma prawo podjąć decyzję o odtworzeniu z kopii i kto odpowiada za komunikat do mieszkańców.

Dlaczego z Fib.Code

Zajmujemy się bezpieczeństwem informacji od strony, z której widać jednocześnie prawo, technologię i ludzi. Prowadzimy funkcję Inspektora Ochrony Danych i Pełnomocnika do spraw bezpieczeństwa informacji w jednostkach samorządu terytorialnego, spółkach komunalnych, podmiotach leczniczych i firmach sektora prywatnego. Budujemy systemy zarządzania bezpieczeństwem informacji zgodne z § 19 Krajowych Ram Interoperacyjności, art. 8 ustawy o krajowym systemie cyberbezpieczeństwa i normą PN-ISO/IEC 27001. Prowadzimy audyty, oceny ryzyka, plany ciągłości działania i szkolenia, po których ludzie wiedzą, co zrobić, a nie tylko czego nie wolno.

Pracujemy według trzech zasad. Po pierwsze, rola przed dokumentem: zanim powstanie jakakolwiek polityka, ustalamy, kto ją wykona, kiedy i na podstawie czego — dokument bez wykonawcy jest kosztem, nie zabezpieczeniem. Po drugie, ryzyko przed zakupem: nie rekomendujemy narzędzi, dopóki nie wiadomo, jakie ryzyko mają obniżyć i o ile. Po trzecie, jeden rejestr zamiast czterech: incydent bezpieczeństwa, naruszenie ochrony danych i zgłoszenie do CSIRT to zwykle to samo zdarzenie widziane z trzech stron, więc prowadzimy je w jednej ewidencji z trzema zegarami.

Produktem końcowym nie jest segregator. Jest nim zestaw działających artefaktów: zarządzenie ustanawiające SZBI z imiennym przypisaniem ról, metodyka szacowania ryzyka wraz z pierwszym przeprowadzonym cyklem i zaakceptowanym planem postępowania, ewidencja systemów z właścicielami, procedura bramki uruchomieniowej, wnioskowy tryb zarządzania uprawnieniami, rejestr incydentów sprzężony z analizą ryzyka oraz harmonogram audytów wewnętrznych z terminami i osobami.

Co zrobić w ten tydzień, zanim zamknie się Wykaz KSC

Jedno spotkanie, sześćdziesiąt minut, cztery osoby: kierownik jednostki lub członek zarządu, sekretarz albo dyrektor administracyjny, osoba odpowiedzialna za IT i inspektor ochrony danych. Na stole trzy rzeczy: aktualna Polityka Bezpieczeństwa Informacji z datą ostatniej zmiany, ewidencja systemów teleinformatycznych oraz rejestr incydentów za ostatnie dwanaście miesięcy.

Sześć pytań do zamknięcia w tej godzinie. Pierwsze: czy złożyliśmy wniosek o wpis do Wykazu podmiotów kluczowych i podmiotów ważnych, a jeżeli uznaliśmy, że nie podlegamy — czy ta ocena jest gdziekolwiek zapisana wraz z uzasadnieniem i datą. Drugie: kto imiennie akceptuje wyniki szacowania ryzyka i kiedy zrobił to ostatni raz. Trzecie: który dokument potwierdza zgodę na uruchomienie ostatniej wdrożonej u nas e-usługi. Czwarte: czy dla każdej pozycji w ewidencji systemów potrafimy wskazać właściciela biznesowego z imienia i nazwiska. Piąte: ile kont w naszych systemach należy do osób, które nie pracują już na stanowisku uprawniającym do dostępu, i kto to sprawdza cyklicznie. Szóste: czy którykolwiek incydent z ostatniego roku zmienił cokolwiek w naszej analizie ryzyka.

Jeżeli przy trzech z sześciu pytań zapadnie cisza, to nie znaczy, że jednostka jest zaniedbana. Znaczy tylko, że ma dokumentację zamiast systemu — tak jak większość podmiotów publicznych w Polsce przed 8 września 2026 roku. Różnica polega na tym, że od tej daty istnieje gotowy, opublikowany w dzienniku urzędowym wzór pokazujący, jak to poukładać. Nie trzeba go wymyślać. Wystarczy go przeczytać i zmniejszyć skalę.

Zapraszamy do kontaktu: l.grabowski@fibcode.com | fibcode.com/pl/kontakt. Bezpośrednio powiązane materiały: Wykaz KSC — 80 tysięcy podmiotów i termin 3 października, KRI w samorządzie terytorialnym — przewodnik, Ransomware w Nowej Rudzie — cyberatak na samorząd a KSC, ISO 27001 — przewodnik wdrożeniowy — cztery teksty o tej samej drodze: od obowiązku prawnego do systemu, który realnie działa.