ISO 27001 Annex A 5.9: asset inventory and named owners

The auditor points at the laptop you're presenting from and asks to see it in the register. Either the row is missing or the owner column says "IT". The same sampling works on an SSO app or a cloud account, and the gap is cheap for them to find.

This guide covers what ISO 27001 Annex A 5.9 requires and how to scope and own a register that survives sampling. It also shows how automation keeps the register current. It is written for security managers, IT leads and compliance owners at 25–250-person firms heading into a Stage 2 or surveillance audit.

What does ISO 27001 Annex A 5.9 require?

ISO 27001 Annex A 5.9 requires a maintained register of information and the assets that carry it, with a named owner against every entry. Those assets include devices, software, cloud infrastructure, facilities and key records. The register must stay accurate as assets are added, changed and retired, because many other controls depend on it.

The control's full name, Inventory of information and other associated assets, signals the scope. It covers the information itself as well as whatever carries it. The standard is pragmatic about form. The inventory can be several living lists kept by the teams closest to the assets, as long as they agree. Nobody expects a row per short-lived virtual machine.

The register is quietly load-bearing for the ISMS, the management system behind your certification:

• Risk assessment. The clause 6 risk assessment is only as complete as the asset list it starts from.
• Incident response. A breach cannot be scoped across systems nobody knew existed.
• Recovery planning. Recovery without dependency knowledge is guesswork.

The NCSC asset management guidance says knowing what assets you have is fundamental to applying effective security controls. It asks for a record of assets that everyone agrees reflects the environment, covering physical, virtual and cloud resources.

The modern failure mode is not the lost laptop. It is the SaaS tool a team bought on a credit card eighteen months ago. It holds customer data, nobody patches it, and your controls cannot see it. Enterprise due-diligence teams and insurers ask the same question in their own words: do you know your estate?

What changed in ISO 27001:2022 for asset inventory and ownership?

ISO 27001:2022 merged two 2013 controls, the asset inventory and asset ownership, into one control. The owner's job also sharpened: a defined set of lifecycle duties running from listing and classification through to secure disposal. Inventory and accountability now sit in a single control.

Treating the two separately let a list exist without anyone answering for it. The 2022 wording closes that gap: the owner is now part of every entry, not a separate list.

If your ISMS was built on the 2013 structure, make three adjustments:

• Merge the documents. Keep one register with an owner field instead of an inventory plus a separate ownership list.
• Rewrite owner responsibilities. Replace vague wording with the lifecycle duties set out in the ownership section below.
• Update the asset management policy. Point it at the single register and widen scope beyond hardware to SaaS, cloud and information holdings.

What counts as an asset before you start counting?

Decide what counts before counting. Cover hardware, software and SaaS, cloud accounts and infrastructure, code repositories, and major information holdings. Record customer data, financials and IP as categories, not individual files. The test is detail that matches how you would actually respond to an incident; short-lived VMs are registered at platform level.

Use these categories as the frame:

• Hardware: laptops, phones, servers and network kit, plus removable media if you allow it.
• Software and SaaS: licensed applications and every subscription tool, including those bought on a corporate card.
• Cloud accounts and infrastructure: AWS accounts, Azure subscriptions, Google Cloud projects and tenants.
• Code repositories: source control organisations and the test environments built from them.
• Major information holdings: customer data, financials and IP, held as categories.

Information holdings are where people overreach. Record "customer data in the production database" with its owner and location, not a row for every file and folder. An incident responder should be able to tell from the register where the data sits and who to call.

Short-lived infrastructure is where firms over-engineer. The standard accepts that VMs and containers cannot be listed one by one. Register the cloud account or platform they run in, and let the tooling account for the instances. The platform's owner answers for what runs on it.

A register that only lists what you can touch is a hardware list, not an inventory.

Who owns an asset: owner versus custodian?

An asset owner is the named person or defined role accountable for an asset across its whole life, from listing and classification to secure disposal. A custodian can do the daily work, such as patching, but accountability is not transferable. 'IT' is not an owner, because no single party would answer for it.

The distinction is practical. The owner answers for the asset in an incident; the custodian looks after it day to day. A platform engineer may patch the database, but the Head of Engineering owns it. A specific role like that works as well as a named person.

Brief every owner on the duties that come with the name:

• Keep the entry current, including location and dependencies.
• Set the classification proportionate to the information the asset holds.
• Sign off access and review who still needs it.
• Make sure usage rules exist for the asset.
• See it securely destroyed when its useful life ends.

The ICO accountability framework on records management and security shows what a register should hold. It expects a register of all information assets, software and hardware, with owners, locations, retention periods and the security measures deployed. For A.5.9, a lean set of columns does the job. Record the owner, classification and location, such as cloud region or office. Add the dependencies that matter for incident and continuity planning, and skip fields you will never query.

"Owner: IT" against every row is ownership by nobody. Owners named in the register may also be asked in interview what owning the asset involves. A fair test before the audit: can each owner explain in two sentences what they sign off and when?

Is a spreadsheet enough, or do you need automated discovery?

At 25–100 people, a well-kept spreadsheet or Notion database is acceptable: auditors certify spreadsheet inventories regularly, and the bar is accuracy and ownership, not tooling. Move to automated discovery feeds when the estate outgrows manual upkeep. An enterprise CMDB earns its place later, if ever; three disagreeing half-registers do the damage.

One source of truth matters more than the tool. Suppose a finance spreadsheet, an IT list and a cloud console export disagree. You cannot answer the auditor's first question: which one is the register? Pick one home, name its maintainer, and let the others feed it. Whichever tool you choose, your asset management policy should name the register, its maintainer and the review cadence.

Three signals say the spreadsheet has done its job:

• The quarterly reconciliation stops being a few hours' work.
• Each reconciliation finds SaaS tools or cloud accounts the register missed.
• Several teams create accounts and subscriptions faster than one maintainer can track.

Vendor pressure is not a signal. The tooling should follow the estate, and the mechanics sit in the final section.

Over-engineering is the opposite failure. An enterprise CMDB bought at 40 people guarantees a maintenance burden, and burdens decay. The standard does not expect one.

The certification-week register is the common trap. It is built once for Stage 2, then left alone until the surveillance audit. Auditors look at edit history, so a version stamp from the week before the audit convinces nobody.

A register built for the audit describes a company that no longer exists.

How do joiners, movers, leavers and disposal keep the inventory current?

Wire register updates into events, not memory. Joiner, mover and leaver steps hand out and recover kit, buying and change processes add entries, and decommissioning removes them. An asset leaves the register only with evidence it was wiped or destroyed. NCSC guidance expects media that held sensitive data to be sanitised before it leaves your control.

The NCSC secure sanitisation and disposal guidance is the reference for the exit. It treats physical destruction as one route, to particles of 6mm or less, with the particle size checked afterwards. We recommend keeping the certificate or wipe log for each disposal and linking it to the register entry, because that record is what the auditor asks to see.

Tie each event to a register action:

• Joiner: the HR event creates a kit-issue task, and the device is recorded against the new starter.
• Mover: a role change triggers a check of the assets and ownership that person holds.
• Leaver: the HR end date triggers recovery of kit and accounts.
• Procurement: approval to buy creates the entry before the asset is used.
• Change management: new cloud accounts, services and tools are registered as part of the change.
• Decommissioning: the entry is removed only once disposal evidence is attached.

Movers and leavers are also where ownership breaks. When a named owner leaves, every asset against their name needs a new owner before their last day. Otherwise the register fails a cross-check against the current staff list.

Two gaps do the damage. Leaver gaps open when offboarding never talks to the register, so kit and accounts outlive the employment. Disposal without a trail leaves old drives in a cupboard, or recycled with no record of wiping. That is a data breach waiting for a skip.

What do auditors test when they reverse-trace your inventory?

Auditors favour reverse-tracing. They pick a physical device in the room, an app on the SSO dashboard or a cloud account from the billing console. Then they ask for its register entry and live owner. Next they trace forward from a leaver to returned kit, and from a disposal to its evidence.

Auditors reach for this control early because it is cheap to test, and a gap here undermines confidence in everything downstream.

Expect questions like these:

• "Show me the inventory. Who maintains it, and when did it last change?"
• "This laptop you're presenting from: find it in the register. Who owns it?"
• "How would a new SaaS subscription end up in here? What if a team signed up without telling IT?"
• "Your last leaver: what happened to their equipment and accounts?"
• "Where did the drives from your last hardware refresh go? Show me the certificate."

Have this evidence set ready:

• The register, with edit history that proves it lives.
• The procedure for adding, changing and retiring entries, and who owns the register itself.
• Owner names you can cross-check against the current staff list.
• Joiner and leaver records for kit that reconcile with HR dates.
• Destruction or sanitisation certificates for retired hardware and media.
• Reconciliation records: the quarterly diff against MDM, cloud and SSO data, and what it caught.
• Registers for awkward categories such as mobile devices, BYOD and removable media, if you allow them.

Each earlier pitfall has a sample that finds it. A hardware-only register fails the SSO-dashboard trace, and "Owner: IT" fails the owner interview. A certification-week register fails on a stale sampled entry, a leaver gap fails the forward trace, and a missing disposal trail fails the last one.

How do you automate asset discovery and catch shadow IT?

Automate by streaming MDM enrolment, cloud provider APIs and the identity provider's application catalogue into one reconciled view. Drift alerts raise a ticket when an unenrolled device signs in or a new SaaS app appears in SSO logs. Ownership tags enforced by policy make unowned assets structurally impossible.

Asset inventory is the strongest automation story among the organisational controls, because the data already exists in machine-readable form. The register stops being recalled from memory and starts being generated from reality.

Three mechanisms carry the load:

• Drift alerts. An unenrolled device authenticating, a new SaaS app in the SSO logs or an untagged cloud resource each raises a ticket at creation time.
• Ownership as metadata. Owner and classification travel as tags in the cloud estate and MDM, enforced by policy, so an untagged resource fails the pipeline.
• Evidence as a by-product. The quarterly reconciliation is a scheduled job, and its output is itself the audit artefact.

SaaS sprawl is caught at creation rather than at year-end. When a team signs up for a tool, the SSO log raises a ticket asking for an owner and a classification. The ticket does not block the sign-up, so teams keep their speed.

Shadow IT is a discovery problem, not a discipline problem.

The table below maps each source to the field it fills and the drift it catches.

Frequently asked questions