IT Asset Register: Excel Template

Ask a sysadmin how many servers the company runs and you get an answer in seconds. Ask in how many places customer personal data is stored, who approves access to each of them, and what happens if one goes down tomorrow morning. Silence - then: “let me check.”

Missing that information causes delays when assessing vulnerabilities, replacing a key administrator, answering security questionnaires, arranging cyber insurance and handling incidents.

A well-maintained asset register helps answer those questions. Many organisations associate it with a hardware list prepared for an audit, although its use is much broader. This article explains what assets mean under ISO 27001, covers seven common misconceptions and shows how to maintain a register even without certification plans. It includes an Excel workbook with 90 example entries for a fictional company using its own server room, AWS, Azure, Google Cloud, containers on OVHcloud and a dozen SaaS services.

What an asset means in ISO 27001

In ISO/IEC 27001:2022 the key control is A.5.9 of Annex A, and the way it is named matters: inventory of information and other associated assets. That name is not cosmetic. In the 2013 edition the control was simply “inventory of assets”, and for a decade it produced hardware lists. The new title emphasises that information is a primary asset, while systems, hardware, people, services and supporting infrastructure are associated assets that enable its processing. ISO/IEC 27001:2022/Amd 1:2024, the climate action amendment, did not change control A.5.9.

The difference is practical, not philosophical. Hardware or a system can often be rebuilt or replaced. A lost customer database, engineering documentation or contract history cannot be bought in a shop.

The inventory should therefore cover information and the associated assets that support its creation, storage, processing, transmission and protection:

information - databases, technical documentation, HR data, contract archives, including paper originals,
software and services - applications, ERP systems, SaaS, containers, CI/CD pipelines,
hardware - servers, storage arrays, laptops, phones, warehouse terminals, PLCs,
supporting infrastructure - power, server room cooling, telecom links, physical access control,
identity and access - the Entra ID tenant, service accounts, API keys, certificates, domains,
external services and supplier dependencies - because they are part of your information processing chain.

The register also underpins several other Annex A controls: A.5.10 (acceptable use), A.5.11 (return of assets when employment ends), A.5.12 and A.5.13 (classification and labelling of information) and A.5.19-A.5.22 (supplier relationships). None of them can be implemented sensibly without knowing what is being returned, classified and entrusted.

Seven misconceptions that ruin asset registers

1. “It’s the fixed asset ledger”

A common mistake looks like this: IT receives the fixed asset list from finance and tries to turn it into a security register.

These are two different documents with two different purposes. Accounting cares about value and depreciation. Security cares about risk. As a result, the fixed asset ledger is missing the most important assets: a CRM subscription at €200 a month is not a fixed asset, yet it holds the entire customer base. A five-year-old laptop has a book value of zero and a disk full of proposals. A domain costs €20 a year, and losing it takes down email and the ordering portal at the same time.

It works the other way too: the ledger is full of items irrelevant to security - furniture, forklifts, office air conditioning.

2. “We have monitoring and a network scanner, so we have a register”

Zabbix, an nmap sweep, the Intune console and the resource list in the AWS console are feeds into the register, not the register. Automation answers “what is running”. It answers none of the questions the register exists for:

who in the business decides on access to this system,
what class of information passes through it,
how many hours of downtime the dependent process survives,
whether a backup exists and whether anyone ever restored from it,
what stops working if we switch it off.

Automated discovery is an excellent complement and catches what the register does not know about. But the business context has to be written once by a human, and after that only maintained.

3. “It has to be complete down to the last unit”

This belief has killed more registers than lack of time. The team starts by recording 140 laptops by serial number, three weeks later nobody remembers why, the file lands on a network share and is never opened again.

The level of detail follows risk, not ambition. A practical rule: something gets its own row when it has its own owner, its own risk or its own contract.

142 identical laptops under one Intune policy can be one summary row if the MDM remains the detailed source of truth and can identify every device, assignee, return and disposal.
One S3 bucket with customer documentation is its own row, even at 200 MB.
One SCADA station controlling the paint line is its own row, even though physically it is an ordinary PC.

The register should contain enough detail to support decisions and the required level of traceability.

4. “The asset owner is the sysadmin”

A register whose “owner” column reads “IT Manager” in every row carries no information at all.

Control A.5.9 requires an owner to be assigned to an asset. Separating business accountability from technical administration is not a mandatory model imposed by the standard, but it usually works well in practice:

business asset owner - the person accountable for how the information is used and who approves access. For the HR system that is the HR manager; for ERP the CFO; for engineering drawings the head of engineering. The risk owner is a separate role and does not always have to be the same person.
technical custodian - whoever administers the asset day to day. It can be an admin, a developer or an external supplier.

This split has a very concrete effect. When the owner is the business, the question “does Kowalski still need access to payroll” reaches the person who knows the answer. When the owner is IT, the answer is “let’s leave it, just in case”.

5. “It’s in the cloud, so it’s the provider’s problem”

The division of responsibility depends on the specific service and on whether you use IaaS, PaaS or SaaS. The provider generally protects the infrastructure and platform components under its control, while the customer remains responsible for areas such as configuration, accounts, permissions, data classification and checking whether retention and recovery meet business requirements.

What that means for the register:

a publicly readable bucket is your incident, not the provider’s outage,
a tenant admin account without MFA is your risk,
compare the retention and recovery features of a SaaS product with your RPO, RTO and accidental or malicious deletion scenarios; if they are insufficient, add an export or backup,
identity configuration - groups, roles and conditional access policies - is often not covered by a complete recovery process, so the register should show how it will be rebuilt.

For more on preparing for a cloud service being unavailable, see Critical SaaS outage: a business continuity plan for your company.

6. “You build the register for the audit”

If a register is updated only before an audit, it does not reflect the real environment for most of the year. It is then difficult to rely on during an incident.

Maintain the register for day-to-day work, such as checking whether a new vulnerability affects systems in use. An up-to-date document also provides useful evidence during an audit.

7. “The standard requires the asset-threat-vulnerability method”

That is a relic of the 2005 edition that still haunts training courses. The 2013 edition and the current 2022 one do not mandate a risk assessment methodology. Clause 6.1.2 requires a consistent, repeatable risk process with risk owners - it does not require you to start from a list of assets.

Organisations that treat the register only as an input to a risk spreadsheet often use more detail than they need. The register also has operational value. Risk can be assessed by scenario, by process or with a mixed method, provided the approach is consistent and produces comparable results.

What a good entry looks like

You do not need thirty columns to start. You need nine, filled with real data:

Column	What to record
ID	A permanent identifier, e.g. `AST-0042`. It stays even when the host is renamed.
Asset name	The name people actually use out loud - hostname, service name, data set name.
Type	Server, virtual machine, container, database, SaaS, identity, data set. The type decides which controls make sense.
Location / provider	Where the data physically sits: server room, cloud region, SaaS provider country.
Business owner	The person who approves access and accepts the risk.
Technical custodian	Who administers it day to day. Can be a supplier.
Information classification	Public, internal, confidential, strictly confidential.
Criticality	Business impact when unavailable.
Last review	The date the owner last confirmed the entry.

Other fields such as RTO, RPO, backup, monitoring, access control, end of support, annual cost and dependencies are useful, but they do not have to be complete on day one. It is better to start with nine reliable columns than to maintain a large workbook containing uncertain data.

Three sample entries, one from each world:

Physical server. AST-0001 · ESXI-HQ-01 · physical server · on-premises, HQ server room · Dell PowerEdge R650, ESXi 8.0 U3 · owner: IT Manager · classification: internal · criticality: critical · RTO 4 h / RPO 24 h · support until 2028-06-30.

Cloud resource. AST-0045 · S3 nordvent-backup-vault · data store · AWS eu-central-1 · Object Lock, 9 TB · owner: IT Manager · classification: strictly confidential · personal data: yes - customers · criticality: critical · this IS the backup, 365-day retention.

SaaS service. AST-0071 · HubSpot CRM Professional · SaaS service · SaaS - USA (SCC + DPF) · 24 seats · owner: Sales Director · classification: confidential · personal data: yes - business contacts · daily API export to S3 · renews 2027-05-31.

Look at the last fields. They are what turns a list into a tool: you know what is a backup, where personal data sits, and when a contract decision is due.

Naming and identifier conventions

A small thing that decides whether the register survives:

The ID is permanent and meaningless. AST-0042 stays with the asset forever, even when the server changes name, role and location. Meaningful IDs (WAW-SRV-ERP-01) break at the first migration.
The name is the one you use in conversation. If everyone says “the old CRM”, put that in the name. A register whose names nobody recognises will not be opened during an incident.
Record dependencies by ID. One “depends on” column replaces the diagram nobody refreshes anyway.
Do not delete retired assets. Change the status to “retired” and keep the date. As long as the disk exists, the asset exists - and a wipe record is the proof that the matter is closed.

The assets companies forget most often

This list comes from real inventories. Something from it is almost always missing:

domains and certificates - who pays for renewal, on whose card, and what happens when that person leaves,
the identity tenant - Entra ID or Google Workspace as an asset in its own right, usually the most critical one in the company,
service accounts and API keys - no owner, no rotation, they outlive every employee,
the backup server - a critical asset and the first target of a ransomware attack,
the OT network and PLCs - off the IT department’s radar, yet they stop production,
telecom links, UPS and server room cooling - a cooling failure shuts the room down in under an hour,
online banking and hardware tokens - the highest financial risk in the company, rarely in the IT register,
shadow IT paid by company card - tools bought by marketing or operations without IT,
the data warehouse and BI reports - a copy of customer data lives there in parallel with the source system,
code repositories and CI/CD runners - they hold deployment tokens to production, so they are production,
paper documents - contract archives, personnel files, the emergency password envelope in the safe,
knowledge held by individuals - you cannot put it in a spreadsheet, but a “technical custodian” column with one name in forty rows says everything.

How much detail for cloud and containers

The most common question on the first attempt is whether to record every instance and every container. Not always. Granularity should follow the organisation’s needs, risk, stored state, ownership and contractual boundaries.

AWS and Azure. Record the account or subscription as an asset in its own right - these form important billing, administration and risk boundaries. Below that, record services with their own state, data or distinct security requirements: the RDS database, significant buckets, the ECS or AKS cluster, the backup vault, the key vault or an entry point such as CloudFront or a load balancer. This does not mean that every bucket must have a row; choose the detail needed for the register’s purpose. Individual tasks, pods and reproducible objects usually do not need their own rows.

Google Cloud. Record the project, then significant BigQuery data sets and buckets. Pay particular attention to service accounts. Avoid long-lived JSON keys where attached identities, impersonation or Workload Identity Federation can be used instead. If a key is unavoidable, assign an owner, minimise its permissions, monitor its use and rotate it regularly.

Dedicated servers and containers, e.g. on OVHcloud. Record the host as an asset, and each production service as its own row depending on that host. Traefik, GitLab, Zabbix, the password manager and the database behind them are five different risks even though they sit on one machine. Do not record helper containers that can be rebuilt from a compose file with no data loss.

It is worth automating at least part of the feed - not to generate entries, but to detect discrepancies:

# AWS: all tagged resources in a region
aws resourcegroupstaggingapi get-resources --region eu-central-1

# Azure: resources in a subscription
az resource list --subscription sub-nordvent-prod --output table

# GCP: resources in a project
gcloud asset search-all-resources --scope=projects/nordvent-analytics-prod

# All containers on a host, including stopped containers
docker ps -a --format json

Once a quarter, compare the output with the register. A difference is either a new asset nobody mentioned, or a zombie you have been paying for since spring.

Why keep a register without ISO 27001

Certification does not have to be the main reason for maintaining a register. It supports day-to-day work in at least eight areas:

1. Vulnerability response time. When a vulnerability similar to Log4Shell appears, the first question is “where do we use this?” An up-to-date register shortens the search and reduces the chance of missing a system.

2. Money. The annual cost column helps identify unused licences, subscriptions left over from completed projects and forgotten test environments. These savings give management a concrete reason to maintain the register.

3. Offboarding. The access control column is a ready-made list of places to revoke access from a leaver. Without it, offboarding ends at disabling the domain account while the CRM login and the SSH key live on.

4. GDPR in practice. Article 30 requires, among other things, categories of recipients and, where applicable, transfers to third countries. It does not explicitly require a list of storage locations, but it is difficult to complete those fields reliably without mapping systems, providers and data flows. The “personal data” and “location / provider” columns can feed the record of processing activities instead of being reconstructed from memory once a year.

5. NIS2. Asset management underpins the risk management requirements. Commission Implementing Regulation (EU) 2024/2690 requires the categories of entities within its scope to maintain a complete, accurate, up-to-date and consistent asset inventory and to keep a traceable history of changes. A spreadsheet can be a starting point, but in that case it should run in an environment that provides versioning and an audit trail. If you are still checking whether the rules apply to you, start with the NIS2 cybersecurity checklist for companies.

6. Business continuity. RTO and RPO without an asset list are a declaration, not a plan. You cannot promise to restore a process in four hours if you do not know how many parts it has.

7. Customer questionnaires and cyber insurance. Customers and insurers often ask how assets are inventoried. An up-to-date register makes it easier to prepare answers and evidence without collecting the data again.

8. Resilience to one person leaving. The register reduces dependence on one administrator’s knowledge and makes it easier for someone else to take over.

How to stop the register dying after one quarter

Registers do not die because of the format. They die because nobody is accountable for accuracy and there is no moment at which an entry is born.

Name a register owner. One person, by name. Not “the IT department”.

Define the entry points. A new entry is created automatically when: hardware or a licence is purchased, an environment is launched, a supplier contract is signed, a project starts, an integration goes live. If entries appear only when someone remembers, the register is dead within a month.

Put the review in the calendar. Once a quarter, business owners confirm their rows - usually 20 minutes per person. The “last review” column tells you whom to remind.

Reconcile with automated sources. Once a quarter, compare the register against Intune, Zabbix and the cloud consoles. The discrepancies are the most interesting part of the exercise.

Tie the register to access requests. If an access request requires an asset ID, the register updates itself, because without an entry the process cannot proceed.

When a spreadsheet stops being enough

A spreadsheet can remain suitable for several hundred entries if it has one owner and a controlled editing process. The signs below help indicate when another tool may be worth considering:

more than three people edit it in parallel and you lose changes,
you need change history: who changed the owner, when and why,
you want to feed the register automatically from cloud and MDM rather than copying by hand,
the register has to link to tickets, changes and incidents.

Then Snipe-IT or GLPI make sense for hardware and licences, NetBox for network infrastructure, or the CMDB module in the ticketing system you already run. Migrating from a well-kept spreadsheet is easy, because the data model already exists.

The template

The file below contains a complete, filled-in example.

Download the IT asset register template - XLSX, 90 entries

Inside there are five sheets:

Asset register - 24 columns and 90 completed rows. The nine core columns are colour-coded, drop-down lists keep values consistent, and conditional formatting highlights critical assets, missing backups, access without MFA, expired support and overdue reviews on its own.
Suppliers - 22 suppliers with data location, processing agreement, responsibility model, SLA, renewal date and exit plan.
Overview - calculates itself. Counts by criticality, provider, type, environment, classification and status, and below them nine register quality checks: assets with no owner, overdue reviews, critical assets with no backup, expired support, access without MFA, personal data outside the EU.
How to use - where to start, a description of every column, and rules for choosing granularity.
Lists - the drop-down values, ready to adapt to your own company.

The data belongs to a fictional company, Nordvent Systems Sp. z o.o. - a ventilation systems manufacturer with 186 employees, a head office in Warsaw with its own server room, a production plant in Płock with an OT network, a B2B ordering portal on AWS, Microsoft 365 and Azure, a data warehouse on Google Cloud, internal tooling in containers on OVHcloud dedicated servers, and a dozen SaaS services.

The data deliberately includes issues found in environments that have grown over many years: a server past end of support, Ubuntu 20.04 on a standby machine, a shared account with the marketing agency, an identity tenant with no configuration backup and a powered-off legacy CRM server whose disk still contains customer data. The workbook therefore demonstrates both the inventory structure and examples of findings that require action.

You may use, copy and modify the file without restriction, including commercially. If you share or write about it, please keep a link back to this article.

The first 30 days

Do not start with everything at once.

Week 1. List the business processes that generate revenue or are required by law - usually five to eight. For each, list the systems it stops without.

Week 2. Fill in the nine core columns for those systems. Do not go below service level. For each row, establish the business owner by name and confirm it with that person.

Week 3. Add identities, suppliers, domains, certificates and backups. This is the layer most often forgotten, and the one that exposes gaps fastest.

Week 4. Open the “Overview” sheet, read the quality checks and turn them into a task list with deadlines. Put the quarterly review in the calendar and name the register owner.

After a month you have a register that genuinely shortens response time. Extending it with RTO, RPO and costs is then a natural next step rather than a precondition.

Summary

An asset register is not a document for the auditor, nor a hardware list. It is the answer to what the company consists of at the information layer, and who is accountable for each part.

A.5.9 is a reference control in Annex A. The organisation determines whether it is necessary through risk treatment and justifies its inclusion or exclusion in the Statement of Applicability. In most information security management systems, however, the absence of a reliable inventory would be difficult to justify. An up-to-date register helps assess the impact of vulnerabilities, control costs and reduce dependence on individual knowledge, regardless of certification plans.

Start with nine columns and a few critical processes. Add further fields when there is a specific need and someone is responsible for keeping them current.

If you want to inventory your environment, sort out owners and access, or connect the register to monitoring, backups and a continuity plan, see our IT Partner service. We can run the inventory and leave you with a register you can actually maintain.