Ustawa o krajowym systemie cyberbezpieczeństwa (KSC), w wersji przyjętej przez Sejm i skierowanej do podpisu przez Prezydenta, implementująca dyrektywę NIS 2, wprowadza istotną zmianę w podejściu do zarządzania aktywami (zob.  https://www.sejm.gov.pl/sejm10.nsf/PrzebiegProc.xsp?nr=1955).  

Zgodnie z nowym art. 8 ust. 1 KSC, podmioty kluczowe i ważne (z wyłączeniem grupy objętej modelem uproszczonym – o czym mowa poniżej) zobowiązane będą do wdrożenia systemu zarządzania bezpieczeństwem informacji (SZBI) w systemach informacyjnych wykorzystywanych w procesach wpływających na świadczenie usługi. Precyzyjna identyfikacja usług i procesów oraz zasobów wspierających ich realizację stanie się wymogiem prawnym. Dlatego organizacja musi rozumieć jakie dostarcza usługi, jakie procesy wpływają na te usługi i jakie systemy IT są wykorzystywane w tych procesach.  

Cele inwentaryzacji

Można wskazać następujące cele inwentaryzacji zasobów. W szczególności chodzi o:  

  • przypisanie odpowiedzialności 
  • zarządzanie podatnościami i cyklem życia 
  • kontrola dostępu  
  • szacowania ryzyka i ciągłość działania 
  • zarządzenie łańcuchem dostawców ICT.  

Rozszerzona definicja „usługi” jako punkt wyjścia inwentaryzacji 

Prawidłowa inwentaryzacja w reżimie NIS 2 nie może ograniczać się do warstwy sprzętowej. Musi ona wychodzić od zidentyfikowania usług świadczonych przez podmiot i następnie systemów które te usługi wspierają. Ustawodawca w uzasadnieniu do projektu (druk nr 1955) oraz w samych przepisach wskazuje na szerokie, funkcjonalne rozumienie tego pojęcia. 

Sektor publiczny 

W przypadku podmiotów publicznych nowelizacja KSC wprowadza wyraźną regułę interpretacyjną wskazującą, że pod pojęciem usługi rozumie się także zadanie publiczne realizowane przez ten podmiot. Oznacza to, że inwentaryzacja musi być skorelowana z katalogiem zadań ustawowych danej jednostki. Uzasadnienie wskazuje, że incydent może doprowadzić do zaprzestania realizacji zadania publicznego, przez co obywatele mogą nie realizować swoich publicznych praw podmiotowych, co z kolei obniża zaufanie do państwa. Zatem każdy system IT, który jest niezbędny do wykonania zadania publicznego (np. wydania decyzji, obsługi wniosku, prowadzenia rejestru), musi zostać zidentyfikowany i zinwentaryzowany. 

Produkcja jako usługa  

W odniesieniu do podmiotów prywatnych, usługę należy rozumieć także szeroko tj. jako działalność gospodarczą służącą do zaspokajania potrzeb ludzi. W tym znaczeniu usługą jest również produkcja przemysłowa. Uzasadnienie projektu podkreśla, że przyjęcie innej interpretacji prowadziłoby do absurdu – gdyby uznać, że produkcja nie jest usługą, podmioty wytwórcze nigdy nie mogłyby zgłosić incydentu poważnego (który definiowany jest jako incydent wpływający na świadczenie usługi), mimo że dyrektywa NIS 2 obejmuje sektor produkcyjny. Konsekwencją tego podejścia jest konieczność objęcia inwentaryzacją także systemów sterowania produkcją i automatyki przemysłowej. 

Zakres przedmiotowy 

Nowelizacja doprecyzowuje definicję systemu informacyjnego (art. 2 pkt 14), wskazując wprost, że obejmuje on „urządzenie lub grupę połączonych urządzeń i oprogramowania zaprogramowanych w celu przetwarzania danych”.  

Jednakże, jak wynika z uzasadnienia, inwentaryzacja nie może ograniczać się wyłącznie do systemów „frontowych” (bezpośrednio świadczących usługę). Projektodawca stoi na stanowisku, że ochroną należy objąć cały ekosystem teleinformatyczny podmiotu, w tym systemy wspierające. Wprost wskazano konieczność uwzględnienia w SZBI: 

  • Systemów Elektronicznego Zarządzania Dokumentacją (EZD), 
  • Sieci wewnętrznych, 
  • Urządzeń końcowych, w tym komputerów, smartfonów i serwerów. 

Podejście to wynika z faktu, że audyt bezpieczeństwa ma dotyczyć całego systemu informacyjnego wykorzystywanego przez podmiot, a nie jedynie jego wycinka.  

Specyfika inwentaryzacji w sektorze publicznym (Załącznik nr 4)

Dla samorządowych podmiotów publicznych będących podmiotami ważnymi (m.in. jednostki budżetowe, zakłady budżetowe, instytucje kultury), ustawodawca przewidział w Załączniku nr 4 odrębny, sformalizowany model inwentaryzacji. 

Uzasadnienie do zmian w KSC wskazuje, że w przypadku mniejszych jednostek samorządowych celowo zrezygnowano z podejścia opartego na ryzyku. Uznano, że podmioty te często nie dysponują personelem zdolnym do przeprowadzenia zaawansowanego szacowania ryzyka. Zamiast tego nałożono na nie obowiązek realizacji „sztywnej” listy wymogów technicznych, w której inwentaryzacja stanowi punkt wyjścia dla pozostałych zabezpieczeń. 

Wymogi Załącznika nr 4 narzucają na administratorów IT w tych jednostkach wymogi w następujących obszarach:  

  • Nakazano inwentaryzację nie tylko sprzętu, ale produktów ICT, usług ICT i procesów ICT służących do przetwarzania informacji. 
  • Podmiot musi kontrolować podstawowe wersje używanych produktów ICT. Ewidencja zasobów musi zatem zawierać precyzyjne informacje o numerach wersji, co jest skorelowane z wymogiem stosowania „stabilnych wersji” wolnych od krytycznych podatności. 
  • System musi obejmować „określanie i kontrolowanie zasad korzystania” z ogólnodostępnych usług chmury obliczeniowej oraz dużych generatywnych modeli sztucznej inteligencji.  
  • Wymagane jest monitorowanie cyklu życia produktów ICT. Ewidencja musi zawierać dane pozwalające na ustalenie daty zakończenia wsparcia producenta, aby zapewnić aktualność systemów. 

Dokumentowanie i aktualizacja

Ustawodawca kładzie duży nacisk na „rozliczalność” procesu inwentaryzacji. W modelu uproszczonym (Załącznik nr 4) przegląd systemu zarządzania bezpieczeństwem informacji, w tym weryfikacja zasobów, musi odbywać się co najmniej raz w roku. 

Dodatkowo, przegląd ten musi być realizowany bezzwłocznie w przypadku: 

  • Wydania rekomendacji przez Pełnomocnika Rządu ds. Cyberbezpieczeństwa dotyczących danych produktów ICT. 
  • Wystąpienia okoliczności wpływających na ryzyko incydentu. 

Podmiot ma obowiązek dokumentowania realizacji tych działań, co oznacza, że sama inwentaryzacja musi mieć formę utrwaloną (np. raport z systemu, zatwierdzony dokument), a nie jedynie odzwierciedlać stan faktyczny w danym momencie. 

Wydaje się że podobny standard – jako minimum – należy przyjąć w stosunku do innych podmiotów, które nie są objęte załącznikiem nr 4.  

Standardy ENISA

Wsparciem w interpretacji ogólnych przepisów ustawy są wytyczne techniczne Agencji Unii Europejskiej ds. Cyberbezpieczeństwa (ENISA) opublikowane w czerwcu 2025 r. W dokumencie Technical implementation guidance on cybersecurity risk-management measures, ENISA wprost wskazuje, że inwentaryzacja musi być procesem ciągłym, zapewniającym kompletność, dokładność i śladowalność zmian w rejestrze. 

ENISA rekomenduje, aby granularność inwentaryzacji wykraczała poza standardowe dane techniczne. Zgodnie z wytycznymi, wpis w rejestrze zasobów powinien zawierać m.in.: unikalny identyfikator (ID), wskazanie właściciela biznesowego (asset owner) i jednostki operacyjnej, lokalizację, datę ostatniej aktualizacji (patch), klasyfikację zgodną z oceną ryzyka, a także kluczową z perspektywy długu technologicznego informację o końcu cyklu życia. 

Podsumowanie 

Projektowane przepisy zmieniają charakter inwentaryzacji z czynności administracyjnej na kluczowy proces bezpieczeństwa. W sektorze publicznym staje się ona precyzyjną listą kontrolną obejmującą wersje oprogramowania i usługi chmurowe, natomiast w sektorze komercyjnym – fundamentem analizy ryzyka dla procesów biznesowych i produkcyjnych. Niewykonanie tych obowiązków – np. brak wdrożenia zarządzania aktywami (art. 8 ust. 1 pkt 2 lit. m) lub niespełnienie wymogów z Załącznika nr 4 (dla podmiotów ważnych publicznych) – jest zagrożone administracyjną karą pieniężną. Co istotne, odpowiedzialność ta może spaść również bezpośrednio na kierownika podmiotu.