Zarządzanie aktywami KSC: katalog danych, właściciele i lineage

Zarządzanie aktywami KSC zaczyna się od danych, a nie od listy sprzętu. Znowelizowana ustawa o KSC wymienia zarządzanie aktywami wśród środków SZBI, które większość podmiotów objętych ustawą musi wdrożyć do 3 kwietnia 2027. Pochodzenie danych (lineage) to zapis, skąd dane pochodzą i przez jakie systemy przechodzą.

Lista serwerów i laptopów nie powie audytorowi, jakie dane przetwarzacie, kto o nich decyduje i skąd płyną. Powie to katalog danych, wskazani właściciele danych i lineage. Tę warstwę budujemy w usłudze data governance i metadane.

Zarządzanie aktywami KSC: czego wymaga ustawa?

Znowelizowana ustawa o KSC (Dz.U. z 2026 r. poz. 252) w art. 8 ust. 1 pkt 2 lit. m wymienia „zarządzanie aktywami” jako środek SZBI, tuż obok polityk kontroli dostępu (lit. n). Źródłem jest art. 21 ust. 2 lit. i dyrektywy NIS2. Ustawa nie określa, jak ma wyglądać wykaz aktywów, więc musicie to ustalić sami.

Najdokładniej opisuje to sekcja 12 załącznika do rozporządzenia wykonawczego (UE) 2024/2690. Wiąże ono bezpośrednio dostawców usług chmurowych, centrów danych, sieci CDN oraz usług zarządzanych (MSP) i zarządzanych usług bezpieczeństwa (MSSP), a także kilka innych usług cyfrowych. Dla pozostałych podmiotów to dobry punkt odniesienia:

• Klasyfikacja (12.1): poziomy klasyfikacji dla wszystkich aktywów, w tym informacji, według poufności, integralności, autentyczności i dostępności.
• Wykaz (12.4.1): pełny, dokładny, aktualny i spójny wykaz aktywów, ze zmianami wpisów rejestrowanymi w sposób identyfikowalny.
• Zawartość (12.4.2): lista działań i usług wraz z systemami sieciowymi i informacyjnymi oraz innymi aktywami, które je wspierają.
• Przegląd (12.4.3): regularny przegląd i aktualizacja wykazu, z udokumentowaną historią zmian.

W sekcji 12 nie pada słowo „właściciel” i nie ma stałej częstotliwości przeglądu. Właściciele wynikają z logiki SZBI: ktoś musi zdecydować o klasyfikacji i zatwierdzić dostęp. Ustawa o KSC dokłada dokumentację techniczną systemu informacyjnego (art. 10 ust. 3 pkt 4) i zapisy potwierdzające, że wymagane czynności zostały wykonane (art. 10 ust. 4).

Dlaczego lista serwerów to jeszcze nie wykaz aktywów?

Bo klasyfikuje się informacje, a nie sprzęt. Wpis w CMDB mówi, że na serwerze bazodanowym działa PostgreSQL w danej serwerowni. Nie mówi, że jeden schemat trzyma dane kontaktowe klientów, drugi faktury, a trzeci to niezamaskowana kopia produkcji do testów. Bez tej wiedzy nie ustalicie poziomu poufności tego serwera.

Podobnie z dostępnością. Pkt 12.1.2 lit. c rozporządzenia każe dopasować wymagania dostępności aktywów do celów odtworzenia z planów ciągłości działania i odtwarzania po awarii. Czas odtworzenia (RTO) ustala się dla usługi i zbioru danych, a nie dla szafy serwerowej.

Wykaz wypełniony na warsztacie przestaje być aktualny po kilku tygodniach. Codziennie przybywa tabel, eksportów z systemów SaaS i raportów. Katalog, który sam pobiera metadane z platformy, nadąża za tym przy niewielkim nakładzie pracy. Arkusz prowadzony ręcznie nie nadąża i jako pierwszy nie spełnia wymogu aktualności.

Co wpisać do katalogu danych pod KSC?

Niewiele, ale konkretnie: jeden wpis na zbiór danych, który wspiera usługę objętą ustawą, z polami, które audytor może porównać z platformą. Rozsądne minimum:

Pole „dane osobowe: tak/nie” przyda się też przy rejestrze czynności przetwarzania z RODO. Nie łączcie jednak tych dokumentów: mają innych właścicieli i innego nadzorcę (UODO zamiast organu właściwego do spraw cyberbezpieczeństwa).

Kim jest właściciel danych, a kim właściciel techniczny?

Właściciel danych to rola biznesowa: osoba, która decyduje, jak wrażliwy jest zbiór, kto może go czytać i jak długo go przechowujecie. Właściciel techniczny dba o to, żeby działał. Gdy obie role łączy jedna osoba z IT, dział IT klasyfikuje dane sprzedaży czy kadr, których sam nie używa i nie potrafi ocenić.

Narzędzia zapisują własność w sensie technicznym. W Databricks Unity Catalog każdy obiekt ma właściciela, który ma do niego wszystkie uprawnienia, w tym prawo nadawania ich innym. Niech będzie nim grupa, np. zespół platformy, a nie osoba, która może odejść. Właściciela biznesowego zapiszcie osobno, np. jako tag.

W dbt każda grupa modeli ma właściciela wskazanego nazwą lub adresem e-mail, a exposures (dashboardy, aplikacje) też muszą go mieć. Dowolne klucze w polu meta, np. właściciel biznesowy czy klasyfikacja, trafiają do generowanej dokumentacji. Informacja o właścicielach danych trafia wtedy do tego samego repozytorium co kod.

Jak pokazać pochodzenie danych (lineage) audytorowi?

Lineage odpowiada na dwa pytania z audytu: skąd pochodzą te dane i co ucierpi, jeśli to źródło zostanie przejęte albo przestanie działać. Obie odpowiedzi zasilają szacowanie ryzyka z art. 8 ust. 1 pkt 1 ustawy o KSC. Narzędzie zależy od Waszej platformy:

• Databricks: Unity Catalog zapisuje lineage automatycznie dla zapytań uruchamianych w Databricks, aż do poziomu kolumn, dla tabel zarejestrowanych w Unity Catalog. Catalog Explorer przechowuje je bezterminowo, a tabele systemowe system.access.table_lineage i system.access.column_lineage tylko z ostatnich 12 miesięcy.
• dbt: graf projektu to lineage między źródłami, modelami i exposures. Zachowujcie wygenerowaną dokumentację dla każdego wydania, żeby pokazać, jak wyglądał przepływ w danym dniu.
• Inne narzędzia: OpenLineage, projekt LF AI & Data Foundation, to otwarty standard zbierania metadanych lineage z uruchamianych zadań.
• Bez platformy danych: jeden plik YAML lub CSV na usługę w repozytorium Git, ze źródłami i celami wpisanymi ręcznie. Historia Gita to identyfikowalny zapis zmian, którego wymaga pkt 12.4.1.

Uważajcie na okres przechowywania. Art. 10 ust. 7 ustawy o KSC każe przechowywać dokumentację bezpieczeństwa co najmniej 2 lata od wycofania jej z użycia. Jeśli lineage jest częścią Waszych dowodów, eksportujcie datowane zrzuty zamiast polegać na rocznym oknie tabeli systemowej.

Co audytor sprawdzi w zarządzaniu aktywami?

Audytor nie czyta całego wykazu. Przygotujcie się na taki przebieg:

1. Wybiera usługę z listy usług i prosi o aktywa, które ją wspierają.
2. Wybiera jeden zbiór danych i pyta o właściciela biznesowego, klasyfikację i datę ostatniego przeglądu.
3. Porównuje, kto ma dostęp, z polityką kontroli dostępu (art. 8 ust. 1 pkt 2 lit. n ustawy o KSC) i z klasyfikacją.
4. Prosi o historię zmian: kiedy powstał wpis, kto zmienił klasyfikację i dlaczego.
5. Szuka w platformie tabeli, której nie ma w wykazie. Jedna taka luka podważa „pełny i dokładny” wykaz w całości.

Podmioty kluczowe od 3 kwietnia 2026, które wcześniej nie były operatorami usług kluczowych, muszą przejść pierwszy audyt KSC (art. 15) do 3 kwietnia 2028; pozostałe podmioty tej kategorii mają na to 24 miesiące od spełnienia kryteriów (Ministerstwo Cyfryzacji, stan na 13 października 2026). Nie przeprowadzamy formalnych audytów KSC. W ramach przeglądu przed audytem KSC sprawdzamy taką próbkę, zanim zrobi to audytor, i mówimy, kto może Was audytować.

Plan uporządkowania aktywów do 3 kwietnia 2027

Od 13 października 2026 zostało niecałe 25 tygodni. Harmonogram z zapasem na próbę generalną:

1. Tygodnie 1-2: lista usług objętych ustawą i właściciel biznesowy dla każdej z nich.
2. Tygodnie 3-6: metadane z platform (Unity Catalog, dbt, katalogi baz danych) w jednym katalogu, uzupełnione o pola z tabeli powyżej.
3. Tygodnie 7-10: właściciele klasyfikują swoje zbiory; IT zapisuje lineage każdej usługi.
4. Tygodnie 11-14: porównanie uprawnień z klasyfikacją i zamknięcie luk.
5. Tygodnie 15-20: polityka zarządzania aktywami i procedura przeglądu, z datą kolejnego przeglądu w kalendarzu.
6. Tygodnie 21-24: próbka przeprowadzona tak, jak zrobi to audytor, i poprawki.

Ten etap wpisuje się w plan wdrożenia KSC na 26 tygodni. O uprawnieniach piszemy w artykule IAM jako podstawa bezpieczeństwa organizacji, a o podstawach własności danych w tekście zarządzanie danymi jako wprowadzenie do AI. Jeśli macie już SZBI według ISO/IEC 27001, jego załącznik A zawiera zabezpieczenia dotyczące inwentarza i klasyfikacji aktywów, które możecie wykorzystać (czym jest ISO/IEC 27001).

Jeśli Wasza firma podlega ustawie, zajrzyjcie na stronę wdrożenie KSC i NIS2 albo napiszcie do nas.