# Rejestr aktywów IT w ISO 27001: szablon Excel z przykładami

> Czym są aktywa w ISO 27001, po co prowadzić rejestr także bez certyfikacji i jak go utrzymać. Gotowy szablon Excel z 90 wypełnionymi wpisami do pobrania.

- Source: https://www.techcroud.com/pl/blog/rejestr-aktywow-it-iso-27001-szablon-excel
- Author: Karol Barański (https://www.linkedin.com/in/karol-baranski-96529a3/)
- Publisher: techcroud.com Sp. z o.o. (https://www.techcroud.com)
- Published: 2026-08-29
- Updated: 2026-08-29
- Language: pl

---
Zapytaj informatyka, ile serwerów ma firma - odpowie w kilka sekund. Zapytaj, w ilu miejscach leżą dane osobowe klientów, kto zatwierdza do nich dostęp i co się stanie, jeśli jutro rano jedno z tych miejsc będzie niedostępne. Zapada cisza, a potem pada zdanie: „muszę sprawdzić”.

Brak takiej wiedzy powoduje opóźnienia przy analizie podatności, odejściu kluczowego administratora, ankietach bezpieczeństwa, zakupie cyberubezpieczenia i obsłudze incydentów.

Pomaga w tym dobrze prowadzony rejestr aktywów. W wielu firmach kojarzy się on ze spisem sprzętu przygotowywanym na potrzeby audytu, choć jego zastosowanie jest znacznie szersze. W tym artykule wyjaśniam, czym są aktywa według ISO 27001, opisuję siedem częstych nieporozumień i pokazuję, jak utrzymywać rejestr także bez planów certyfikacji. Do artykułu dołączony jest arkusz Excel z 90 przykładowymi wpisami fikcyjnej firmy korzystającej z własnej serwerowni, AWS, Azure, Google Cloud, kontenerów na OVH i kilkunastu usług SaaS.

## Czym jest aktywo w ISO 27001

W normie ISO/IEC 27001:2022 kluczowa jest kontrola **A.5.9 Aneksu A** i to, jak została nazwana: *inwentaryzacja informacji i innych powiązanych aktywów*. Ta nazwa to nie kosmetyka. W wersji z 2013 roku kontrola nazywała się po prostu „inwentaryzacja aktywów” i przez dekadę produkowała spisy sprzętu. Nowa nazwa podkreśla, że **informacja jest aktywem pierwotnym, a systemy, sprzęt, ludzie, usługi i infrastruktura wspierają jej przetwarzanie i również są aktywami powiązanymi**. Poprawka ISO/IEC 27001:2022/Amd 1:2024 dotycząca zmian klimatycznych nie zmieniła treści kontroli A.5.9.

Różnica jest praktyczna, nie filozoficzna. Sprzęt lub system często da się odtworzyć albo wymienić. Utraconej bazy klientów, dokumentacji konstrukcyjnej albo historii korespondencji z kontrahentem nie kupisz w sklepie.

Rejestr powinien więc obejmować informacje oraz powiązane aktywa, które wspierają ich tworzenie, przechowywanie, przetwarzanie, przesyłanie i ochronę:

- **informacje** - bazy danych, dokumentacja techniczna, dane kadrowe, archiwum umów, także w wersji papierowej,
- **oprogramowanie i usługi** - aplikacje, systemy ERP, usługi SaaS, kontenery, pipeline'y CI/CD,
- **sprzęt** - serwery, macierze, laptopy, telefony, terminale magazynowe, sterowniki PLC,
- **infrastruktura wspierająca** - zasilanie, klimatyzacja serwerowni, łącza telekomunikacyjne, kontrola dostępu,
- **tożsamości i dostęp** - tenant Entra ID, konta serwisowe, klucze API, certyfikaty, domeny,
- **usługi zewnętrzne i zależności od dostawców** - bo są częścią waszego łańcucha przetwarzania informacji.

Rejestr aktywów jest przy okazji fundamentem kilku innych kontroli z Aneksu A: A.5.10 (dopuszczalne użycie), A.5.11 (zwrot aktywów przy zakończeniu zatrudnienia), A.5.12 i A.5.13 (klasyfikacja i oznaczanie informacji) oraz A.5.19-A.5.22 (relacje z dostawcami). Żadnej z nich nie da się sensownie wdrożyć, jeśli nie wiadomo, co się właściwie zwraca, klasyfikuje i komu powierza.

## Siedem nieporozumień, które psują rejestry aktywów

### 1. „To przecież ewidencja środków trwałych”

Częsty błąd wygląda tak: dział IT dostaje z księgowości plik ze środkami trwałymi i próbuje zrobić z niego rejestr bezpieczeństwa.

To dwa różne dokumenty o dwóch różnych celach. Księgowość interesuje wartość i amortyzacja. Bezpieczeństwo interesuje ryzyko. W efekcie **w ewidencji środków trwałych nie ma najważniejszych aktywów**: subskrypcja CRM za 900 zł miesięcznie nie jest środkiem trwałym, a trzyma całą bazę klientów. Zamortyzowany do zera laptop sprzed pięciu lat ma wartość księgową 0 zł i pełny dysk dokumentacji ofertowej. Domena firmowa kosztuje 80 zł rocznie, a jej utrata wyłącza jednocześnie pocztę i portal zamówień.

Odwrotnie też: w ewidencji jest mnóstwo pozycji nieistotnych dla bezpieczeństwa - meble, wózki widłowe, klimatyzatory w biurze.

### 2. „Mamy monitoring i skaner sieci, więc mamy rejestr”

Zabbix, skan nmap, konsola Intune i lista zasobów w konsoli AWS to **źródła zasilania** rejestru, a nie rejestr. Automat odpowie na pytanie „co działa”. Nie odpowie na żadne z pytań, dla których rejestr powstaje:

- kto z biznesu decyduje o dostępie do tego systemu,
- jakiej klasy informacje przez niego przechodzą,
- ile godzin przestoju wytrzyma proces, który na nim stoi,
- czy istnieje kopia zapasowa i czy ktoś ją kiedykolwiek odtwarzał,
- co przestanie działać, jeśli to wyłączymy.

Automatyczna inwentaryzacja jest świetnym uzupełnieniem i pozwala wykryć to, o czym rejestr nie wie. Ale kontekst biznesowy trzeba dopisać ręcznie - raz, a potem tylko aktualizować.

### 3. „Rejestr musi być kompletny co do sztuki”

To przekonanie zabiło więcej rejestrów niż brak czasu. Zespół zaczyna od spisywania 140 laptopów po numerach seryjnych, po trzech tygodniach nikt już nie pamięta, po co to robił, plik ląduje na dysku sieciowym i nigdy nie zostaje otwarty.

Poziom szczegółowości wynika z ryzyka, a nie z ambicji. Praktyczna zasada: **osobny wpis dostaje to, co ma osobnego właściciela, osobne ryzyko albo osobną umowę**.

- 142 identyczne laptopy z tą samą polityką w Intune mogą być jednym wierszem podsumowującym, jeśli MDM pozostaje szczegółowym źródłem prawdy i pozwala zidentyfikować każde urządzenie, użytkownika, zwrot oraz likwidację.
- Jeden bucket S3 z dokumentacją klientów to osobny wiersz, nawet jeśli waży 200 MB.
- Jedna stacja SCADA sterująca linią lakierniczą to osobny wiersz, nawet jeśli fizycznie to zwykły pecet.

Rejestr powinien mieć tyle szczegółów, ile potrzeba do podejmowania decyzji i zachowania wymaganej identyfikowalności.

### 4. „Właścicielem aktywa jest informatyk”

Rejestr, w którym w kolumnie „właściciel” we wszystkich wierszach widnieje kierownik IT, nie niesie żadnej informacji.

Kontrola A.5.9 wymaga przypisania właściciela aktywa. Rozdzielenie odpowiedzialności biznesowej od administracji technicznej nie jest obowiązkowym modelem narzuconym przez normę, ale zwykle dobrze działa w praktyce:

- **właściciel biznesowy aktywa** - osoba, która odpowiada za sposób wykorzystania informacji i zatwierdza dostępy. Dla systemu kadrowego to kierownik HR, dla ERP dyrektor finansowy, dla dokumentacji konstrukcyjnej główny konstruktor. Właściciel ryzyka jest rolą odrębną i nie zawsze musi być tą samą osobą.
- **opiekun techniczny** - kto administruje aktywem na co dzień. Może to być administrator, deweloper albo firma zewnętrzna.

Ten podział ma bardzo konkretny skutek. Gdy właścicielem jest biznes, pytanie „czy Kowalski nadal potrzebuje dostępu do modułu płac” trafia do osoby, która zna odpowiedź. Gdy właścicielem jest IT, odpowiedź brzmi „na wszelki wypadek zostawmy”.

### 5. „To jest w chmurze, więc to problem dostawcy”

Zakres współdzielonej odpowiedzialności zależy od konkretnej usługi i od tego, czy korzystacie z IaaS, PaaS czy SaaS. Dostawca zwykle chroni infrastrukturę i elementy platformy pozostające pod jego kontrolą, a klient nadal odpowiada m.in. za konfigurację, konta, uprawnienia, klasyfikację danych oraz sprawdzenie, czy retencja i odtwarzanie spełniają wymagania firmy.

Praktyczne konsekwencje dla rejestru:

- publicznie dostępny bucket to wasz incydent, nie awaria dostawcy,
- konto administratora tenanta bez MFA to wasze ryzyko,
- funkcje retencji i odtwarzania oferowane przez SaaS trzeba porównać z waszym RPO, RTO i scenariuszami przypadkowego lub złośliwego usunięcia; jeśli są niewystarczające, potrzebny jest dodatkowy eksport albo backup,
- konfiguracja tożsamości (grupy, role, polityki dostępu warunkowego) często nie jest objęta pełnym procesem odtworzeniowym - rejestr powinien pokazać, jak zostanie odbudowana.

Więcej o tym, jak przygotować się na niedostępność usługi chmurowej, znajdziesz w tekście [Awaria kluczowej usługi SaaS: plan ciągłości działania dla firmy](/pl/blog/awaria-saas-plan-ciaglosci-dzialania-dla-firmy).

### 6. „Rejestr robi się na audyt”

Jeżeli rejestr jest aktualizowany tylko przed audytem, przez większą część roku nie odzwierciedla rzeczywistego środowiska. Podczas incydentu trudno wtedy na nim polegać.

Prowadź rejestr tak, żeby pomagał w zwykłej pracy, na przykład przy ocenie, czy nowa podatność dotyczy używanych systemów. Aktualny dokument jest później również użytecznym dowodem podczas audytu.

### 7. „Norma wymaga metodyki aktywa - zagrożenia - podatności”

To relikt normy z 2005 roku, który wciąż pokutuje w szkoleniach. Wersja z 2013 roku i obecna z 2022 **nie narzucają metodyki szacowania ryzyka**. Punkt 6.1.2 wymaga, żebyście mieli spójny, powtarzalny proces oceny ryzyka i żeby ryzyka miały właścicieli - ale nie wymaga, żeby wychodzić od listy aktywów.

Firmy, które traktują rejestr wyłącznie jako wejście do arkusza ryzyk, często schodzą do niepotrzebnego poziomu szczegółowości. Rejestr ma również wartość operacyjną. Ryzyko można oceniać scenariuszowo, procesowo albo metodą mieszaną, o ile podejście jest spójne i daje porównywalne wyniki.

## Jak wygląda dobry wpis

Nie potrzebujesz trzydziestu kolumn na start. Potrzebujesz dziewięciu, wypełnionych prawdziwymi danymi:

| Kolumna | Co wpisać |
| --- | --- |
| ID | Stały identyfikator, np. `AST-0042`. Nie zmienia się nawet po zmianie nazwy hosta. |
| Nazwa aktywa | Nazwa, której naprawdę używacie w rozmowie - hostname, nazwa usługi, nazwa zbioru danych. |
| Typ | Serwer, maszyna wirtualna, kontener, baza, SaaS, tożsamość, zbiór danych. Typ decyduje, jakie zabezpieczenia mają sens. |
| Lokalizacja / dostawca | Gdzie fizycznie leżą dane: serwerownia, region chmury, kraj dostawcy SaaS. |
| Właściciel biznesowy | Osoba z biznesu, która zatwierdza dostępy i akceptuje ryzyko. |
| Opiekun techniczny | Kto administruje na co dzień. Może to być dostawca. |
| Klasyfikacja informacji | Publiczna, wewnętrzna, poufna, ściśle poufna. |
| Krytyczność | Wpływ na biznes przy niedostępności. |
| Ostatni przegląd | Data potwierdzenia wpisu przez właściciela. |

Pozostałe pola, takie jak RTO, RPO, kopia zapasowa, monitoring, kontrola dostępu, koniec wsparcia, koszt roczny i zależności, są przydatne, ale nie muszą być kompletne pierwszego dnia. Lepiej zacząć od dziewięciu rzetelnie uzupełnionych kolumn niż utrzymywać rozbudowany arkusz z niepewnymi danymi.

Trzy przykładowe wpisy, po jednym z każdego świata:

**Serwer fizyczny.** `AST-0001 · ESXI-HQ-01 · serwer fizyczny · on-premises, serwerownia HQ · Dell PowerEdge R650, ESXi 8.0 U3 · właściciel: kierownik IT · klasyfikacja: wewnętrzna · krytyczność: krytyczna · RTO 4 h / RPO 24 h · wsparcie do 2028-06-30.`

**Zasób chmurowy.** `AST-0045 · S3 nordvent-backup-vault · magazyn danych · AWS eu-central-1 · Object Lock, 9 TB · właściciel: kierownik IT · klasyfikacja: ściśle poufna · dane osobowe: tak - klienci · krytyczność: krytyczna · to JEST kopia zapasowa, retencja 365 dni.`

**Usługa SaaS.** `AST-0071 · HubSpot CRM Professional · usługa SaaS · SaaS - USA (SCC + DPF) · 24 stanowiska · właściciel: dyrektor sprzedaży · klasyfikacja: poufna · dane osobowe: tak - kontrahenci · eksport przez API do S3 raz dziennie · odnowienie 2027-05-31.`

Zwróć uwagę na ostatnie pola. To one zamieniają spis w narzędzie: wiadomo, co jest kopią, gdzie leżą dane osobowe i kiedy trzeba podjąć decyzję o odnowieniu umowy.

## Konwencja nazw i identyfikatorów

Drobiazg, który decyduje o tym, czy rejestr da się utrzymać:

- **ID jest stałe i nic nie znaczy.** `AST-0042` zostaje z aktywem do końca, nawet gdy serwer zmieni nazwę, rolę i lokalizację. Znaczące identyfikatory (`WAW-SRV-ERP-01`) psują się przy pierwszej migracji.
- **Nazwa jest taka, jakiej używacie w rozmowie.** Jeśli wszyscy mówią „stary CRM”, to niech to będzie w nazwie. Rejestr, którego nazwy nikt nie rozpoznaje, nie zostanie użyty podczas incydentu.
- **Zależności zapisuj po ID.** Jedna kolumna „zależy od” zastępuje diagram, którego i tak nikt nie odświeży.
- **Nie usuwaj wycofanych aktywów.** Zmień status na „wycofane” i zostaw datę. Dopóki dysk istnieje, aktywo istnieje - a protokół kasowania to dowód, że sprawa jest zamknięta.

## Aktywa, o których firmy zapominają najczęściej

Ta lista powstała z rzeczywistych inwentaryzacji. Prawie zawsze czegoś z niej brakuje:

- **domeny i certyfikaty** - kto płaci za odnowienie, na czyją kartę i co się stanie, gdy ta osoba odejdzie,
- **tenant tożsamości** - Entra ID lub Google Workspace jako osobne aktywo, zwykle najbardziej krytyczne w całej firmie,
- **konta serwisowe i klucze API** - nie mają właściciela, nie mają rotacji, przeżywają wszystkich pracowników,
- **serwer kopii zapasowych** - jest aktywem krytycznym i pierwszym celem ataku ransomware,
- **sieć OT i sterowniki PLC** - poza radarem działu IT, a zatrzymują produkcję,
- **łącza telekomunikacyjne, UPS i klimatyzacja serwerowni** - awaria klimatyzacji wyłącza serwerownię w kilkadziesiąt minut,
- **bankowość elektroniczna i tokeny** - najwyższe ryzyko finansowe w firmie, rzadko w rejestrze IT,
- **shadow IT opłacane kartą firmową** - narzędzia kupione przez marketing i produkcję z pominięciem IT,
- **hurtownia danych i raporty BI** - kopia danych klientów żyje tam równolegle do systemu źródłowego,
- **repozytoria kodu i runnery CI/CD** - mają tokeny wdrożeniowe do produkcji, więc same są produkcją,
- **dokumenty papierowe** - archiwum umów, teczki osobowe, koperta z hasłami awaryjnymi w sejfie,
- **wiedza pojedynczych osób** - nie wpiszesz jej do arkusza, ale kolumna „opiekun techniczny” z jednym nazwiskiem w czterdziestu wierszach mówi wszystko.

## Ile szczegółów w chmurze i w kontenerach

Najczęstsze pytanie przy pierwszym podejściu: czy wpisywać każdą instancję i każdy kontener? Nie zawsze. Granularność powinna wynikać z potrzeb organizacji, ryzyka, stanu przechowywanego przez usługę, właściciela i umowy.

**AWS i Azure.** Wpisz konto lub subskrypcję jako osobne aktywo - wyznaczają ważne granice rozliczeń, administracji i ryzyka. Dalej wpisuj usługi, które mają własny stan, dane albo wymagają odrębnych zabezpieczeń: bazę RDS, istotne buckety, klaster ECS lub AKS, magazyn kopii, key vault czy punkt wejścia (CloudFront, load balancer). Nie jest to wymóg wpisywania każdego bucketu; poziom szczegółowości dobierz do celu rejestru. Pojedyncze zadania, pody i odtwarzalne obiekty zwykle nie potrzebują własnych wierszy.

**Google Cloud.** Wpisz projekt, a potem istotne zbiory danych BigQuery i buckety. Zwróć szczególną uwagę na konta serwisowe. Długotrwałych kluczy JSON najlepiej unikać na rzecz dołączonych tożsamości, impersonacji lub Workload Identity Federation. Jeśli klucz jest niezbędny, trzeba przypisać mu właściciela, ograniczyć uprawnienia, monitorować użycie i regularnie go rotować.

**Serwery dedykowane i kontenery, np. w OVH.** Wpisz host jako aktywo, a każdą usługę produkcyjną jako osobny wiersz z zależnością od hosta. Traefik, GitLab, Zabbix, menedżer haseł i baza dla nich wszystkich to pięć różnych ryzyk, mimo że stoją na jednej maszynie. Nie wpisuj kontenerów pomocniczych, które można odtworzyć z pliku compose bez utraty danych.

Zasilanie rejestru warto zautomatyzować choćby częściowo - nie po to, żeby generować wpisy, tylko żeby wykrywać rozbieżności:

```bash
# AWS: wszystkie otagowane zasoby w regionie
aws resourcegroupstaggingapi get-resources --region eu-central-1

# Azure: zasoby w subskrypcji
az resource list --subscription sub-nordvent-prod --output table

# GCP: zasoby w projekcie
gcloud asset search-all-resources --scope=projects/nordvent-analytics-prod

# Wszystkie kontenery na hoście, także zatrzymane
docker ps -a --format json
```

Raz na kwartał porównaj wyniki z rejestrem. Różnica to albo nowe aktywo, o którym nikt nie powiedział, albo zombie, za które płacicie od pół roku.

## Dlaczego warto prowadzić rejestr bez ISO 27001

Certyfikacja nie musi być głównym powodem prowadzenia rejestru. W codziennej pracy przydaje się on co najmniej w ośmiu obszarach:

**1. Czas reakcji na podatność.** Gdy pojawia się podatność podobna do Log4Shell, pierwsze pytanie brzmi „gdzie tego używamy”. Aktualny rejestr znacznie skraca poszukiwanie odpowiedzi i ogranicza ryzyko pominięcia systemu.

**2. Pieniądze.** Kolumna z kosztem rocznym pomaga znaleźć niewykorzystywane licencje, subskrypcje pozostałe po zakończonych projektach i zapomniane środowiska testowe. Takie oszczędności są dla zarządu konkretnym uzasadnieniem utrzymywania rejestru.

**3. Offboarding.** Kolumna „kontrola dostępu” to gotowa lista miejsc, z których trzeba odebrać dostęp odchodzącemu pracownikowi. Bez niej offboarding kończy się na wyłączeniu konta w domenie, a konto w CRM i klucz SSH żyją dalej.

**4. RODO w praktyce.** Art. 30 RODO wymaga m.in. wskazania kategorii odbiorców oraz, gdy ma to zastosowanie, transferów do państw trzecich. Nie nakazuje wprost prowadzenia listy lokalizacji przechowywania, ale bez mapy systemów, dostawców i przepływów trudno rzetelnie uzupełnić te informacje. Kolumny „dane osobowe” i „lokalizacja / dostawca” mogą zasilać rejestr czynności przetwarzania zamiast być odtwarzane z pamięci raz w roku.

**5. NIS2 i KSC.** Zarządzanie aktywami jest podstawą wymogów zarządzania ryzykiem - rozporządzenie wykonawcze Komisji (UE) 2024/2690 wprost wymaga od objętych nim kategorii podmiotów prowadzenia kompletnej, dokładnej, aktualnej i spójnej inwentaryzacji oraz śledzenia historii zmian. Arkusz może być punktem startu, ale w takim przypadku powinien działać w środowisku zapewniającym wersjonowanie i audyt zmian. Jeśli dopiero sprawdzacie, czy przepisy was dotyczą, zacznij od [checklisty NIS2 i KSC 2026](/pl/blog/nis2-ksc-2026-checklista-cyberbezpieczenstwa-dla-firm).

**6. Ciągłość działania.** RTO i RPO bez listy aktywów są deklaracją, nie planem. Nie da się obiecać przywrócenia procesu w cztery godziny, jeśli nie wiadomo, z ilu elementów ten proces się składa.

**7. Ankiety klientów i cyberubezpieczenie.** Klienci i ubezpieczyciele często pytają o sposób prowadzenia inwentaryzacji. Aktualny rejestr ułatwia przygotowanie odpowiedzi i dowodów bez zbierania danych od początku.

**8. Odporność na odejście jednej osoby.** Rejestr ogranicza zależność od wiedzy jednego administratora i ułatwia przejęcie obowiązków przez inną osobę.

## Jak sprawić, żeby rejestr nie umarł po kwartale

Rejestr nie umiera z powodu złego formatu. Umiera dlatego, że nikt nie odpowiada za jego aktualność i nie ma momentu, w którym powstaje wpis.

**Wyznacz właściciela rejestru.** Jedna osoba, imiennie. Nie „dział IT”.

**Zdefiniuj punkty wejścia.** Nowy wpis powstaje automatycznie przy: zakupie sprzętu lub licencji, uruchomieniu środowiska, podpisaniu umowy z dostawcą, starcie projektu, wdrożeniu integracji. Jeśli wpis powstaje tylko wtedy, gdy ktoś sobie przypomni, rejestr jest martwy od pierwszego miesiąca.

**Wpisz przegląd do kalendarza.** Raz na kwartał właściciele biznesowi potwierdzają swoje wiersze - to zwykle 20 minut na osobę. Kolumna „ostatni przegląd” pokazuje, komu przypomnieć.

**Uzgadniaj ze źródłami automatycznymi.** Raz na kwartał porównaj rejestr z Intune, Zabbiksem i konsolami chmurowymi. Rozbieżności są najciekawszą częścią tego ćwiczenia.

**Powiąż rejestr z nadawaniem dostępu.** Jeśli wniosek o dostęp wymaga wskazania ID aktywa, rejestr aktualizuje się sam, bo bez wpisu nie da się przejść procesu.

## Kiedy Excel przestaje wystarczać

Arkusz może wystarczać także przy kilkuset wpisach, jeśli ma jednego właściciela i kontrolowany sposób edycji. Podane niżej sygnały pomagają ocenić, kiedy warto rozważyć inne narzędzie:

- rejestr edytuje równolegle więcej niż trzy osoby i tracicie zmiany,
- potrzebujecie historii zmian: kto, kiedy i dlaczego zmienił właściciela,
- chcecie automatycznie zasilać rejestr z chmury i MDM, a nie kopiować ręcznie,
- rejestr musi być powiązany ze zgłoszeniami, zmianami i incydentami.

Wtedy sensowne są Snipe-IT lub GLPI dla sprzętu i licencji, NetBox dla infrastruktury sieciowej, albo moduł CMDB w używanym już systemie zgłoszeń. Migracja z dobrze prowadzonego arkusza jest wtedy prosta, bo model danych już istnieje.

## Szablon do pobrania

Poniższy plik zawiera kompletny, **wypełniony** przykład.

**[Pobierz szablon rejestru aktywów IT - XLSX, 90 wpisów](/downloads/rejestr-aktywow-it-iso-27001-szablon-techcroud.xlsx)**

W środku znajdziesz pięć arkuszy:

- **Rejestr aktywów** - 24 kolumny i 90 wypełnionych wierszy. Dziewięć kolumn podstawowych oznaczono kolorem, listy rozwijane pilnują spójności wartości, a formatowanie warunkowe samo podświetla aktywa krytyczne, brak kopii zapasowej, dostęp bez MFA, wygasłe wsparcie i przeglądy po terminie.
- **Dostawcy** - 22 dostawców z lokalizacją danych, umową powierzenia, modelem odpowiedzialności, SLA, datą odnowienia i planem wyjścia.
- **Przegląd** - liczy się sam. Podsumowanie według krytyczności, dostawcy, typu, środowiska, klasyfikacji i statusu, a pod nim dziewięć kontroli jakości rejestru: aktywa bez właściciela, przeglądy po terminie, krytyczne aktywa bez kopii, wygasłe wsparcie, dostęp bez MFA, dane osobowe poza UE.
- **Instrukcja** - jak zacząć, opis wszystkich kolumn i zasady doboru szczegółowości.
- **Słowniki** - wartości list rozwijanych, gotowe do zmiany pod własną firmę.

Dane należą do fikcyjnej firmy **Nordvent Systems Sp. z o.o.** - producenta systemów wentylacyjnych ze 186 pracownikami, centralą w Warszawie z własną serwerownią, zakładem produkcyjnym w Płocku z siecią OT, portalem zamówień B2B na AWS, Microsoft 365 i Azure, hurtownią danych w Google Cloud, narzędziami wewnętrznymi w kontenerach na serwerach dedykowanych OVHcloud i kilkunastoma usługami SaaS.

Dane celowo zawierają problemy spotykane w rozwijanych przez lata środowiskach: serwer po końcu wsparcia, Ubuntu 20.04 na maszynie zapasowej, konto współdzielone z agencją marketingową, tenant tożsamości bez kopii konfiguracji i wyłączony serwer starego CRM, którego dysk z danymi klientów wciąż istnieje. Dzięki temu arkusz pokazuje nie tylko sposób ewidencji, ale też przykłady ustaleń wymagających działania.

Możesz używać, kopiować i modyfikować plik bez ograniczeń, także komercyjnie. Jeśli udostępniasz go dalej lub opisujesz, zostaw odnośnik do tego artykułu.

## Pierwsze 30 dni

Nie zaczynaj od wszystkiego naraz.

**Tydzień 1.** Wypisz procesy biznesowe, które przynoszą przychód albo wynikają z przepisów - zwykle jest ich pięć do ośmiu. Dla każdego wypisz systemy, bez których staje.

**Tydzień 2.** Uzupełnij dziewięć podstawowych kolumn dla tych systemów. Nie schodź niżej niż do poziomu usługi. Przy każdym wierszu ustal nazwisko właściciela biznesowego i potwierdź je z tą osobą.

**Tydzień 3.** Dodaj tożsamości, dostawców, domeny, certyfikaty i kopie zapasowe. To warstwa, o której zapomina się najczęściej, a która najszybciej ujawnia luki.

**Tydzień 4.** Otwórz arkusz „Przegląd”, przeczytaj kontrole jakości i zamień je na listę zadań z terminami. Wpisz przegląd kwartalny do kalendarza i wskaż właściciela rejestru.

Po miesiącu masz rejestr, który realnie skraca czas reakcji. Rozszerzanie o RTO, RPO i koszty jest wtedy naturalnym krokiem, a nie warunkiem startu.

## Podsumowanie

Rejestr aktywów nie jest dokumentem dla audytora ani spisem sprzętu. Jest odpowiedzią na pytanie, z czego składa się firma w warstwie informacji i kto za każdy element odpowiada.

A.5.9 jest kontrolą referencyjną Aneksu A. Organizacja ocenia jej niezbędność w procesie postępowania z ryzykiem i uzasadnia zastosowanie albo wyłączenie w deklaracji stosowania. W większości systemów zarządzania bezpieczeństwem informacji trudno byłoby jednak uzasadnić brak wiarygodnej inwentaryzacji. Aktualny rejestr pomaga ocenić wpływ podatności, kontrolować koszty i ograniczać zależność od wiedzy pojedynczych osób, niezależnie od planów certyfikacyjnych.

Na początek wystarczy dziewięć kolumn i kilka najważniejszych procesów. Kolejne pola można dodawać wtedy, gdy pojawi się konkretna potrzeba i osoba odpowiedzialna za ich aktualność.

Jeśli chcesz zinwentaryzować środowisko, uporządkować właścicieli i dostępy albo połączyć rejestr z monitoringiem, kopiami i planem ciągłości działania, zobacz usługę [Partner IT](/pl/partner-it). Możemy przeprowadzić inwentaryzację i zostawić wam rejestr, który da się utrzymać.