ISO 27001 A.5.9: What actually belongs in your asset register

Your IT firm or consulting agency wants to certify to ISO 27001. Maybe a corporate client added it as a requirement in their RFP. Maybe your cyber insurance broker is asking for the certificate to lower the premium. Maybe clients keep asking "how do you protect our data?" and you would like a concrete answer.

You read Annex A and find A.5.9: "Inventory of information and other associated assets". Sounds cryptic. What exactly must be in this register? How many fields? Who is the owner? What if you have 200 laptops and 30 SaaS subscriptions?

This article breaks A.5.9 down. Not from a corporate auditor's perspective — from the perspective of a small IT company, MSP or consulting firm doing this for the first time and wanting to do it right so you do not repeat it.

What A.5.9 actually says

The official text of the control in Annex A of ISO/IEC 27001:2022:

> "An inventory of information and other associated assets, including owners, should be developed and maintained."

Let us unpack that sentence:

What the register must contain — minimum fields

The standard does not spell out fields word-for-word, but in practice auditors expect the following:

Required fields (no auditor will accept these missing)

**Asset ID** — serial number for hardware, unique identifier for documents, databases, licences.

**Asset type** — physical hardware, software or licence, document or information, service (e.g. SaaS subscription), infrastructure.

**Description** — a readable name: "Dell XPS 15 laptop, backend developer", "CRM customer database", "NDA with Client X".

**Owner** — the name of the person, not a title. The person accountable for decisions about the asset, not the sysadmin who administers it. For a developer laptop pool the owner might be the CTO, not the sysadmin.

**Location** — where the asset physically resides: office, employee home, cloud (provider named), client site. For information: where the data is stored.

**Information classification** — the confidentiality level per your classification policy. Typical levels: public, internal, confidential, strictly confidential. This requires classification policy (A.5.12) to be defined first — auditors will pull that thread.

Expected fields (auditor will note absence but may accept if the rest is solid)

Date entered into register.

**Date of last review** — when the owner last confirmed the asset exists and matches the register. Without this date, the register is not being "maintained".

**Status** — active, in maintenance, retired, destroyed. Retired assets stay in the register with the appropriate status — they do not vanish.

**Date and method of disposal (for retired)** — when the asset was destroyed, the secure disposal method (for hardware with data storage), the certificate of destruction.

Optional fields (raise the quality of the register and support other controls)

**Accounting inventory number** — if the asset is also a fixed asset in accounting. Reconciles the ISO register with the accounting ledger.

**Warranty / licence / subscription end date** — for renewal planning and budgeting.

**Book value** — supports risk management and replacement decisions.

**Related assets** — the server running a specific database; the laptop where a licence is installed.

Most common gaps auditors find

ISO 27001 auditors have their favourite findings. These show up in most first audits at small firms:

Gap 1: Hardware register without information or licences

The firm shows a list of 40 laptops. The auditor asks: "Where are the databases? SaaS licences? Client documents?". "We do not have that yet" is a nonconformity — A.5.9 explicitly requires "information and other associated assets".

Add all SaaS subscriptions (type: service / software), client contracts (type: document), databases (type: information).

Gap 2: Owner = team, not a person

The "owner" field says "IT", "HR", "engineering team". Auditor: "Who exactly? If I ask that person about the confidentiality classification, who answers?"

Every asset must have a named person. For many similar assets (e.g. all laptops), one accountable person can cover the pool — but it must be a name.

Gap 3: Static register — no evidence of maintenance

An Excel register with creation date six months ago, no modification date, no new entry despite three laptops purchased in the interim. "How was the register maintained in the last six months?" "We update it annually" does not meet the maintenance requirement.

Update on every change (new asset, owner change, status change). Quarterly review of the whole register. Change log with date and person for every edit.

Gap 4: No retired-asset trail

An employee left three months ago; their laptop vanishes from the register; their system access is not marked as revoked. Auditor: "How do I know access was revoked when there is no trail in the register?"

Retired assets stay in the register with status "retired" and date. A separate "assigned to" field lets you trace who had the asset at any moment.

Gap 5: Classification without a policy

Auditor: "I see you mark assets as 'confidential'. What policy defines that classification?". Firm: "...we do not have one, we just eyeball it". Result: nonconformity with A.5.12 (Classification of information), which must be satisfied before the classification column of the asset register makes sense.

Start with a classification policy (four levels: public, internal, confidential, strictly confidential, with definitions for each). Then classify assets against it.

Sample entry — what a good record looks like

A developer laptop in a 15-person firm should look like this:

That is the minimum to move the auditor off this row to the next question.

Excel vs dedicated system

Excel works up to about 30–50 assets. Above that, quality erodes: inconsistent columns, deleted entries instead of retired-tagged, no audit trail of edits, no access control (anyone with the link can change anything), no integration with the rest of the business.

A dedicated register solves five things Excel does not:

How [Asseto](/for/it-companies) satisfies A.5.9

Asseto was built with the asset register as a first-class concept. Every field A.5.9 expects has a home in the system. Owner is a required field. Last-review date updates automatically on every quarterly verification. Retired assets stay in the register with status "retired" and date — they do not disappear the way they do in a spreadsheet when somebody hits delete.

The PDF export of the register carries every field auditors expect, timestamped and cryptographically signed. It is the same file you hand to the auditor — no reconciling three spreadsheets the week before the audit.

Build the register before you need the certificate

The worst time to build an asset register is the week before your certification audit. Owners do not remember who received what eight months ago. Retired assets have no disposal date. Confidentiality classification gets done "by eye" without a policy.

Start today. List every laptop, SaaS subscription, client contract and database. Assign an owner to each. Set the classification. Schedule the quarterly review. In a month you have a register that will pass the audit. In a year you have a register that reduces incident risk — because you can see who has access to what.

[Try Asseto free](/signup) and stand up an A.5.9-compliant asset register in less than an hour. CSV import from an existing spreadsheet in five minutes. Owner assignments in twenty. Classification in thirty. You walk into the ISO 27001 audit with a register the auditor ticks off in the first hour.