Inwentaryzacja usług, procesów i aktywów ICT w małej JSFP – jak zacząć na potrzeby KSC

Wdrażanie obowiązków wynikających z ustawy o krajowym systemie cyberbezpieczeństwa łatwo rozpocząć od polityk, procedur albo zakupu narzędzi bezpieczeństwa. W praktyce lepiej zacząć wcześniej: od ustalenia, jakie zadania i usługi realizuje jednostka, jakie procesy są potrzebne do ich wykonania oraz od jakich systemów, usług ICT i dostawców te procesy zależą.

Bez takiej mapy trudno racjonalnie określić zakres systemu zarządzania bezpieczeństwem informacji (SZBI), ustalić najważniejsze systemy, ocenić skutki ich niedostępności czy wskazać priorytety zabezpieczeń.

Dla podmiotu ważnego będącego podmiotem publicznym obowiązek jest bardzo konkretny. Część I pkt 1 załącznika nr 4 do ustawy o KSC wymaga inwentaryzacji produktów ICT, usług ICT i procesów ICT służących do przetwarzania informacji. Załącznik wymaga również kontrolowania podstawowych wersji używanych produktów i usług ICT. Z kolei w modelu wynikającym z art. 8 ust. 1 ustawa wprost wymienia zarządzanie aktywami jako jeden ze środków organizacyjnych i technicznych.

Nie oznacza to jednak, że mała jednostka pierwszego dnia powinna budować rozbudowaną CMDB, czyli bazę elementów konfiguracji środowiska ICT zawierającą tysiące pozycji. Najpierw potrzebna jest czytelna mapa działalności i najważniejszych zależności. Dopiero później należy zwiększać szczegółowość ewidencji.

Najpierw ustal status jednostki

Samo bycie jednostką sektora finansów publicznych (JSFP) nie przesądza ani o podleganiu ustawie o KSC, ani o właściwym modelu SZBI.

Przed rozpoczęciem inwentaryzacji prowadzonej na potrzeby KSC trzeba ustalić, czy jednostka jest objęta ustawą, jaki ma status oraz czy stosuje model z art. 8 ust. 1, czy szczególny model określony w art. 8 ust. 3 i załączniku nr 4.

Określenie „pełny model z art. 8 ust. 1” używane w tym artykule jest jedynie skrótem redakcyjnym, a nie terminem ustawowym. Art. 8 ust. 3 wyłącza stosowanie ust. 1 m.in. wobec wskazanej kategorii podmiotów ważnych będących podmiotami publicznymi i nakazuje im stosować SZBI spełniający wymagania załącznika nr 4.

Szczególnej ostrożności wymaga np. ochrona zdrowia. W aktualnym Q&A Ministerstwo Cyfryzacji wskazuje, że samodzielny publiczny zakład opieki zdrowotnej zatrudniający poniżej 50 pracowników co do zasady nie podlega ustawie o KSC. Sam dokument Q&A nie ma jednak mocy prawnej, co Ministerstwo wyraźnie zaznacza. Ponadto kwalifikacja może wymagać odrębnej analizy, jeżeli podmiot wykonuje również działalność należącą do innego sektora objętego ustawą albo zostanie indywidualnie uznany za podmiot kluczowy lub ważny. Ustawa przewiduje możliwość takiego uznania w drodze decyzji w przypadkach określonych w art. 7l.

Artykuł dotyczy jednostki, dla której wcześniej potwierdzono podleganie ustawie o KSC.

Po co inwentaryzacja w KSC

Inwentaryzacja nie jest celem samym w sobie. Powinna pozwalać odpowiedzieć na pytania: jakie zadania jednostka realizuje, jakie procesy są do tego potrzebne, jakie rozwiązania ICT te procesy wspierają, kto za nie odpowiada, gdzie przetwarzane są informacje, od jakich dostawców jednostka zależy oraz jakie mogą być skutki awarii, utraty danych albo naruszenia bezpieczeństwa.

W modelu art. 8 ust. 1 SZBI obejmuje system informacyjny wykorzystywany w procesach wpływających na świadczenie usługi, a jednym z wymaganych środków jest zarządzanie aktywami — art. 8 ust. 1 pkt 2 lit. m.

W modelu art. 8 ust. 3 część I pkt 1 załącznika nr 4 wymaga natomiast wprost inwentaryzacji produktów ICT, usług ICT i procesów ICT służących do przetwarzania informacji.

Dlatego zwykły spis komputerów albo ewidencja środków trwałych nie wystarczą. Inwentaryzacja na potrzeby cyberbezpieczeństwa powinna przede wszystkim pokazywać związek między działalnością jednostki a technologią, która tę działalność umożliwia.

Trzy warstwy, nie jeden „CMDB marzeń”

Dla małej JSFP praktycznym początkiem jest model:

zadanie lub usługa publiczna → proces → system / produkt / usługa ICT

Przykładowo w urzędzie obsługa spraw mieszkańców może zależeć od procesu przyjęcia, rejestracji i prowadzenia sprawy, a ten od e-Doręczeń, EZD, poczty oraz właściwego systemu dziedzinowego.

W szkole zadaniem będzie np. realizacja procesu kształcenia, jednym z procesów — prowadzenie dokumentacji przebiegu nauczania, a wykorzystywanymi rozwiązaniami — e-dziennik, system sekretariatu czy poczta elektroniczna.

Pierwsza mapa małej jednostki może obejmować przykładowo 15–40 najważniejszych relacji biznesowo-systemowych. Nie jest to próg wynikający z ustawy. Jest to jedynie praktyczna metoda rozpoczęcia pracy bez ugrzęźnięcia od pierwszego dnia w setkach urządzeń i komponentów.

Następnie dla istotnych rozwiązań należy zwiększać szczegółowość i ujmować m.in. usługi, wersje, serwery, urządzenia sieciowe, bazy danych, domeny, integracje, mechanizmy backupu czy zależności od dostawców.

Źródła danych, które już są

Inwentaryzacji nie trzeba zaczynać od pustej kartki. Informacje potrzebne do przygotowania pierwszej mapy zwykle są już w jednostce, ale pozostają rozproszone.

Rozmowy z pracownikami bywają szczególnie wartościowe. Dokumentacja pokazuje często środowisko, które powinno istnieć, natomiast wywiad ujawnia środowisko rzeczywiście wykorzystywane.

W ten sposób mogą pojawić się rozwiązania SaaS zakupione poza IT, dodatkowe programy w księgowości, arkusze z makrami pełniące funkcję aplikacji, zewnętrzne formularze albo usługi chmurowe uruchomione bez formalnego procesu wdrożenia.

Właściciel merytoryczny, administrator techniczny i opiekun rekordu

Ustawa nie narzuca poniższego podziału ról. Jest to rekomendowana praktyka organizacyjna, która ułatwia utrzymanie aktualnej ewidencji.

• Właściciel merytoryczny / odpowiedzialna komórka powinien wiedzieć, do czego rozwiązanie służy, jakie zadanie i proces wspiera, kto z niego korzysta oraz jaki będzie skutek niedostępności.
• Administrator techniczny powinien znać sposób utrzymania rozwiązania, jego wersję, lokalizację, backup, integracje, zasady aktualizacji oraz sposób wykonywania czynności administracyjnych i serwisowych.
• Opiekun rekordu odpowiada za aktualizację wpisu po zmianie rozwiązania. Funkcja ta może być połączona z jedną z dwóch wcześniejszych ról.

Przykładowo właścicielem merytorycznym systemu finansowo-księgowego może być główny księgowy, administratorem technicznym — informatyk lub dostawca, a opiekunem rekordu osoba wyznaczona do prowadzenia ewidencji ICT.

Nie należy automatycznie przypisywać informatyka jako właściciela wszystkich systemów.

Dane osobowe to nie jedyny rodzaj chronionej informacji

Informacja o przetwarzaniu danych osobowych jest potrzebna, ale bezpieczeństwa informacji nie można sprowadzać wyłącznie do RODO.

Nie chodzi o kopiowanie do arkusza całego rejestru czynności przetwarzania ani o wykonywanie w nim DPIA. Jeżeli jednostka prowadzi już ewidencje na potrzeby ochrony danych, lepiej powiązać informacje między rejestrami, niż utrzymywać dwa niezależne i potencjalnie sprzeczne opisy tych samych zasobów.

Lokalizacja przetwarzania

Pole „lokalizacja” nie musi oznaczać wyłącznie numeru pomieszczenia z serwerem. Może wskazywać np. infrastrukturę własną, CUW, centrum danych dostawcy, chmurę publiczną, SaaS albo system dostarczony przez inny podmiot publiczny.

Ostatnia sytuacja jest szczególnie ważna. Art. 8 ust. 4 stanowi, że podmiot publiczny uwzględnia w SZBI również system informacyjny dostarczany przez inny podmiot publiczny, w szczególności system zapewniający działanie rejestru publicznego — w zakresie odpowiadającym kompetencjom danego podmiotu, wynikającym z polityki bezpieczeństwa danego systemu albo przepisów prawa regulujących sposób jego działania.

Stwierdzenie „to nie jest nasz system” nie jest wystarczającym argumentem, aby pominąć go w mapie zależności.

Dostawca i zależność

System nie kończy się na aplikacji widocznej na ekranie użytkownika. System finansowo-księgowy może zależeć od bazy danych, serwera, infrastruktury sieciowej, backupu, dostawcy oprogramowania i zdalnego serwisu. BIP może zależeć od CMS, hostingu, DNS, rejestratora domeny i łącza internetowego.

Dopiero pokazanie takich relacji pozwala zrozumieć rzeczywiste źródła ryzyka i punkty, których awaria może wpłynąć na działalność jednostki.

W modelu art. 8 ust. 1 bezpieczeństwo i ciągłość łańcucha dostaw produktów ICT, usług ICT i procesów ICT są wprost jednym z wymaganych obszarów SZBI. Przy stosowaniu tych środków podmiot powinien uwzględniać m.in. podatności związane z dostawcą oraz ogólną jakość dostarczanych produktów, usług i procesów ICT.

W modelu załącznika nr 4 część II przewiduje natomiast fakultatywne dodatkowe środki, w tym zapisy zapewniające odpowiedni poziom bezpieczeństwa w umowach serwisowych z podmiotami trzecimi. Sformułowanie „może dodatkowo obejmować” oznacza, że nie należy przedstawiać tych środków jako katalogu obowiązkowego.

Jak nie utonąć — zasada 80/20

Pierwszego tygodnia nie trzeba spisywać każdego monitora, drukarki, adresu IP i biblioteki programistycznej.

Najpierw należy odnaleźć rozwiązania, których niedostępność może rzeczywiście zatrzymać lub istotnie utrudnić wykonywanie zadań: pocztę elektroniczną, EZD, finanse i księgowość, kadry i płace, BIP, systemy dziedzinowe, mechanizmy uwierzytelniania, podstawowe usługi sieciowe i kopie zapasowe.

Dla szkoły szybko pojawi się e-dziennik. Dla podmiotu leczniczego objętego KSC mogą to być HIS, EDM, LIS, RIS/PACS czy rozwiązania współpracujące z urządzeniami medycznymi.

Zasada 80/20: najpierw zidentyfikuj najważniejsze zależności, a następnie zwiększaj szczegółowość. Nie oznacza ona, że zinwentaryzowanie tylko najważniejszych 20% środowiska wystarczy do spełnienia obowiązków ustawowych.

Arkusz startowy — mapa działalności i zależności

Pierwszy arkusz ma odpowiadać przede wszystkim na pytanie: który proces zależy od którego systemu lub usługi?

Jeden wiersz — jedna relacja

Jeżeli jeden proces korzysta z kilku systemów lub usług, każdą relację najlepiej zapisać w osobnym wierszu. Nie warto wpisywać w jednej komórce: „EZD, e-Doręczenia, poczta, system podatkowy, plik Excel”. Taki zapis szybko uniemożliwi filtrowanie i analizę.

Lepiej utworzyć osobne relacje:

• proces A → EZD;
• proces A → e-Doręczenia;
• proces A → poczta;
• proces A → system dziedzinowy.

Dzięki temu można później łatwo odwrócić pytanie i sprawdzić, które procesy przestaną działać, jeżeli niedostępny będzie system X.

Pierwszy arkusz jest punktem wyjścia do rozwijania inwentaryzacji produktów ICT, usług ICT i procesów ICT służących do przetwarzania informacji, wymaganej przez część I pkt 1 załącznika nr 4.

Szczegółowa inwentaryzacja ICT

Drugi arkusz rozwija informacje o poszczególnych pozycjach.

Taki model umożliwia stopniowe przechodzenie od wiedzy o działalności do szczegółowej wiedzy o środowisku, bez mieszania procesu ICT, usługi ICT i produktu ICT w jednym niejednoznacznym polu.

Jak określić krytyczność

Skala 1–5 nie wynika z ustawy. Jest narzędziem organizacyjnym.

Ważniejsze od samej liczby jest uzasadnienie krytyczności. Jeżeli system otrzymuje poziom 5, po pół roku nadal powinno być wiadomo, dlaczego tak zdecydowano.

Zapytaj właściciela merytorycznego: co stanie się z realizacją zadania, jeżeli system będzie niedostępny przez godzinę, dzień albo tydzień?

Chroń również sam rejestr

Szczegółowa inwentaryzacja ICT sama staje się informacją wymagającą ochrony. Może ujawniać wykorzystywane produkty i ich wersje, rozwiązania po zakończeniu wsparcia, lokalizację systemów, zależności infrastrukturalne, dostawców czy sposób utrzymania środowiska. Taka wiedza mogłaby być przydatna również potencjalnemu atakującemu.

Dlatego dostęp do szczegółowego rejestru powinien być ograniczony do osób, które rzeczywiście go potrzebują. Zmiany warto wersjonować, wykonywać kopie zapasowe i zapewnić możliwość odtworzenia wcześniejszego stanu.

W rejestrze nie należy przechowywać haseł, kluczy kryptograficznych, kodów odzyskiwania, tokenów, sekretów aplikacyjnych ani innych danych uwierzytelniających.

Można odnotować, że system posiada np. konto administracyjne albo mechanizm MFA, ale same dane dostępowe powinny znajdować się w odpowiednim, zabezpieczonym rozwiązaniu do zarządzania sekretami lub hasłami.

Data przeglądu nie może być dekoracją

Inwentaryzacja nie jest dokumentem sporządzanym jednorazowo. Systemy są wymieniane, dostawcy się zmieniają, pojawiają się nowe usługi SaaS, integracje i migracje do chmury.

W modelu załącznika nr 4 podmiot dokonuje przeglądu SZBI co najmniej raz w roku, a także bezzwłocznie m.in. po wystąpieniu okoliczności mogących wpłynąć na ryzyko incydentu poważnego. Część IV załącznika wymaga również dokumentowania realizacji działań wskazanych do wykonania w SZBI.

Niezależnie od tego warto przyjąć praktyczną zasadę bieżącej aktualizacji rejestru po wdrożeniu lub wycofaniu systemu, zmianie dostawcy, migracji do chmury, zmianie wersji o istotnym znaczeniu, uruchomieniu nowej integracji czy zmianie sposobu przetwarzania informacji.

Zmiana środowiska powinna prowadzić do zmiany rejestru, a nie do oczekiwania na kolejny coroczny przegląd.

Co zrobić z wynikiem w dwa tygodnie

Dwutygodniowy harmonogram nie wynika z KSC. To praktyczny sposób przygotowania pierwszej użytecznej mapy w niewielkiej jednostce.

1. Dni 1–2 — zadania i usługi. Zbierz statut, regulamin organizacyjny i BIP oraz wskaż najważniejsze zadania.
2. Dni 3–4 — procesy. Rozpisz główne procesy potrzebne do realizacji zadań.
3. Dni 5–7 — systemy i usługi ICT. Ustal z właścicielami merytorycznymi, z jakich rozwiązań korzysta każdy proces. Porównaj odpowiedzi z umowami, dokumentacją IT i RODO, ewidencją sprzętu oraz narzędziami technicznymi.
4. Dni 8–9 — dostawcy i lokalizacja. Ustal dostawców, miejsce działania i podstawę korzystania z rozwiązania.
5. Dni 10–11 — krytyczność. Oceń skutki niedostępności wspólnie ze stroną merytoryczną.
6. Dni 12–13 — weryfikacja. Przejrzyj mapę z IT, IOD i przedstawicielami najważniejszych komórek merytorycznych.
7. Dzień 14 — priorytety. Wskaż najważniejsze systemy i zależności wymagające dalszej analizy.

Dalsza ścieżka zależy od właściwego modelu:

• art. 8 ust. 1: inwentaryzacja → zakres SZBI → zależności → szacowanie i zarządzanie ryzykiem → środki bezpieczeństwa → działania;
• art. 8 ust. 3 i załącznik nr 4: inwentaryzacja → zakres SZBI → wymagania załącznika nr 4 → identyfikacja luk → działania → dokumentowanie realizacji.

Art. 8 ust. 3 wprost stanowi, że wskazany w nim podmiot nie stosuje art. 8 ust. 1, lecz SZBI zgodny z załącznikiem nr 4. Nie oznacza to, że analiza ryzyka w takim podmiocie jest niepożądana — może być wartościowym narzędziem pomocniczym. Nie należy jednak przedstawiać całego mechanizmu art. 8 ust. 1 jako automatycznego obowiązku tego podmiotu.

Najczęstsze błędy

„Mamy ewidencję środków trwałych”

Nie pokazuje ona procesów, usług SaaS, integracji ani zależności od dostawców.

„System utrzymuje dostawca, więc nie musimy go ujmować”

Sposób utrzymania systemu zmienia charakter zależności, ale jej nie usuwa.

„Właścicielem każdego systemu jest informatyk”

IT odpowiada za technologię, natomiast znaczenie rozwiązania dla zadania powinno zostać potwierdzone przez stronę merytoryczną.

„Najpierw zinwentaryzujemy wszystko do poziomu każdego urządzenia”

W niewielkiej jednostce może to opóźnić rozpoznanie najważniejszych zależności.

„Mamy listę pięciu kluczowych aplikacji, więc inwentaryzacja jest gotowa”

Lista priorytetowych systemów jest wartościowym etapem projektu, ale nie należy utożsamiać jej z całym zakresem inwentaryzacji wymaganej przez właściwy model SZBI.

Podsumowanie

Dobra inwentaryzacja na potrzeby KSC nie zaczyna się od numeru seryjnego laptopa. Zaczyna się od pytania:

Jakie zadanie realizujemy i od czego zależy jego wykonanie?

Praktyczny ciąg wygląda następująco:

zadanie / usługa → proces → system / produkt / usługa ICT → infrastruktura → dostawca → odpowiedzialność → znaczenie dla działalności

W małej jednostce pierwszym narzędziem może być zwykły arkusz kalkulacyjny. Kluczowe nie jest posiadanie zaawansowanej CMDB, lecz wiedza o rzeczywistym środowisku, jego właścicielach, zależnościach oraz aktualnym stanie.

Dopiero na tej podstawie można sensownie budować SZBI, identyfikować luki, analizować ryzyko w zakresie wynikającym z właściwego modelu i ustalać kolejność wdrażania zabezpieczeń.

Zobacz także

• Zarządzanie ryzykiem cyberbezpieczeństwa w JSFP
• Bezpieczeństwo łańcucha dostaw IT – wymagania dla dostawców
• Załącznik nr 4 do ustawy o KSC – wymagania SZBI
• Pełny SZBI z art. 8 ust. 1 a model z art. 8 ust. 3
• Czy każda JSFP podlega ustawie o KSC?

Źródła i podstawa prawna

1. Ustawa z 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa, t.j. Dz.U. z 2026 r. poz. 20, ze zm., w brzmieniu nadanym m.in. ustawą 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) — w szczególności art. 7l, art. 8 ust. 1–4 oraz załącznik nr 4. Nowelizacja weszła w życie 3 kwietnia 2026 r. Ustawa o KSC w ELI ↗; ustawa nowelizująca w ELI ↗.
2. Ministerstwo Cyfryzacji, Q&A dotyczące nowelizacji KSC, aktualizacja z czerwca 2026 r. — materiał pomocniczy dotyczący m.in. kwalifikacji podmiotów publicznych, modelu SZBI oraz statusu SPZOZ. Ministerstwo zastrzega, że dokument nie ma mocy prawnej i nie jest wiążący. Q&A Ministerstwa Cyfryzacji ↗.

Artykuł ma charakter informacyjny. Zaproponowane arkusze, role, skala krytyczności, liczba pozycji startowych i dwutygodniowy harmonogram są rekomendowaną metodą organizacyjną. Nie są formularzem ani szczegółową metodą narzuconą przez ustawę. Zakres inwentaryzacji należy dostosować do statusu podmiotu, właściwego modelu SZBI, realizowanych zadań oraz rzeczywistego środowiska ICT.