ISO 27001 Asset Inventory (A.5.9–A.5.11): An Asset Register That Survives Audits

One of the first evidence requests in almost every ISO 27001 audit is the same: show us your asset inventory. It comes early for a reason. The register reveals in about two minutes whether your ISMS describes your actual company or a template's idea of one. An inventory listing twelve laptops and a file server, presented by a cloud-native SaaS company with forty SaaS subscriptions and three production AWS accounts, tells the auditor exactly how the rest of the audit is going to go.

This post covers the three Annex A controls that govern the asset lifecycle — A.5.9, A.5.10 and A.5.11 — what auditors actually check, and how to build a register that stays accurate without becoming someone's part-time job.

What A.5.9 actually requires

Control A.5.9, Inventory of information and other associated assets, asks for exactly two things: an inventory of information and other associated assets, including owners, that is developed and maintained. In the 2022 revision it merged two 2013 controls — A.8.1.1 (inventory of assets) and A.8.1.2 (ownership of assets) — into one. The merge is telling: an inventory without accountable owners was never worth much on its own.

Three words in the control text carry most of the weight:

• Information. It comes first in the control's title, and that's deliberate. The inventory is not primarily a hardware list — it's a map of the information your company holds and the things that store, process, or transmit it.
• Owners. Every asset needs an assigned owner: a person or role responsible for the asset across its lifecycle — how it's classified, who gets access to it, and what happens when it's retired. "The company" is not an owner. Neither is a committee.
• Maintained. A register built once during audit prep and never touched again fails the control even if every row was accurate on the day it was written. Maintenance is the requirement, not a nice-to-have.

An "asset" is not just a laptop

For a cloud-native company, most of the register isn't physical. A useful way to think about scope:

• Information assets: customer data sets, production databases, source code, financial records, employee personal data, contracts, credentials and secrets.
• Software and services: your SaaS tenants (Google Workspace, GitHub organization, Slack, CRM), cloud accounts and subscriptions, and the services you build and run yourself.
• Endpoints: laptops and any phones that hold company data — usually the smallest part of the register, not the whole of it.
• Supporting assets: domains, TLS certificates, API keys, and signing keys. These are attacker favorites and are routinely missing from startup registers.

On granularity: inventory at the level where you make security decisions. Endpoints need per-device entries (you'll need them for returns under A.5.11), while "production customer database" can be one entry with one owner even if it spans several physical instances. A thousand-row register nobody reads is not more compliant than a sixty-row register somebody maintains.

A.5.10 and A.5.11: the rest of the same lifecycle

A.5.10, Acceptable use of information and other associated assets, requires rules for acceptable use — and procedures for handling assets — to be identified, documented, and implemented. In practice this is your Acceptable Use Policy plus handling rules that follow from classification: what can be stored where, what can leave the company, what happens to data on personal devices.

A.5.11, Return of assets, requires personnel and other interested parties — contractors included — to return all organizational assets in their possession when their employment or contract ends or changes. The evidence is your offboarding records: device returned, access revoked, information handed over or deleted.

The three controls are one lifecycle, not three projects: know what you have (A.5.9), say how it may be used (A.5.10), and get it back (A.5.11). The dependency runs through the register — you can only return what you knew the person had. This is why a weak inventory shows up as findings in places that look unrelated, offboarding above all.

The register: columns that earn their place

Every column in an asset register is a promise to keep it filled in. Make few promises and keep them:

Resist adding columns you won't maintain. An empty "recovery point objective" column on every row is a finding generator, not diligence.

Auto-generated beats hand-kept

Most of your inventory already exists in systems that are paid to know the truth: your MDM knows every enrolled laptop, your cloud provider knows every resource, your identity provider knows every SaaS application behind SSO, your repo host knows every repository. A hand-kept spreadsheet duplicating those sources is a snapshot that starts decaying the day it's saved.

The pattern that survives audits: generate the technical asset classes from those systems of record, and keep a curated layer on top for information assets and ownership — the part only humans know. The register then references live sources instead of copying them, and producing evidence auditors accept becomes an export rather than an archaeology project. This is precisely the approach AuditBadger's automated evidence collection is built around: pull the inventory from the systems that already have it, and let humans own what only humans can.

How auditors test it

Expect the register to be sampled in both directions, and expect the people in it to be interviewed:

• Register → reality: pick a row, show the asset. A laptop from the register should exist in the MDM; a data set should be where the register says it is.
• Reality → register: pick an application from your SSO portal or a production account from your cloud console, and find it in the register. Shadow SaaS that never made it in is the classic finding.
• Owner interviews: "You're listed as the owner of the production database — what does that involve?" An owner who didn't know they were one is a finding wearing a name tag.
• Leaver trace: a recent departure from the HR list, followed to a return-of-assets record under A.5.11.
• Dates: a "last reviewed" column where every row shares the same date — one week before the audit — says exactly what you think it says.
• Scope consistency: the register should agree with your ISMS scope from Clause 4. Assets outside scope in the register, or in-scope systems missing from it, both raise questions.

One cross-framework note: if you're also pursuing SOC 2®, the work transfers — the points of focus for CC6.1 in the AICPA Trust Services Criteria include identifying and managing an inventory of information assets. One honest register serves both examinations.

The asset inventory is unglamorous, which is exactly why it's such a reliable signal. Where the register is real, the rest of Annex A usually is too — access reviews have populations, offboarding has checklists, and the risk assessment has something concrete to assess. Build it from systems of record, give every row an owner who knows it, and it stops being audit prep and starts being the map you run security from.