ISO 27001 Asset Inventory: Ownership, Coverage and Audit Evidence

An ISO/IEC 27001 asset inventory should help an organisation answer three practical questions: what needs protection, who is accountable for it, and which risk decisions depend on it. A spreadsheet of laptops may support those questions, but it is not the whole inventory. Important assets also include information, business services, applications, cloud resources, facilities, people-related knowledge and externally provided services.

The useful starting point is the information and service the organisation needs, followed by the supporting assets that enable it. That structure gives risk assessment, ownership and control selection a common reference point.

Understand what the inventory is for

Annex A control 5.9 addresses an inventory of information and other associated assets, including ownership. Related controls address acceptable use and return of assets. ISO 27001 does not prescribe a particular tool, column set or single central database.

The inventory should support the organisation’s risk-based ISMS. It can therefore be assembled from several controlled sources, provided the relationship between them is clear. A configuration management database may describe infrastructure, an identity platform may describe accounts, a SaaS register may cover subscriptions, and a records catalogue may describe information. What matters is reliable coverage and accountability, not forcing every asset into one oversized table.

An accounting fixed-asset register serves a different purpose. It normally focuses on financial value and tangible property. Security needs may include assets with little book value but high confidentiality, integrity or availability impact.

Use an information-first asset model

Start with business services and information sets, then map the people, technology, facilities and suppliers that support them.

For example, an online billing service may depend on customer account data, a payment application, cloud databases, identity services, developers, operational runbooks and an external payment provider. Treating each item as an isolated row loses the dependency chain. Linking them makes it easier to understand what a database failure, privileged-account compromise or supplier outage could affect.

A practical hierarchy is:

1. Business service or process — the outcome the organisation must deliver.
2. Information — the records, data sets or knowledge used by the service.
3. Primary owner — the role accountable for protection and acceptable use.
4. Supporting assets — applications, infrastructure, endpoints, facilities, people and suppliers.
5. Dependencies — upstream services, shared platforms and external connections.

This model also strengthens the risk register because risk scenarios can point to a meaningful service and impact rather than an unexplained device identifier.

Decide which fields earn their place

The standard does not define mandatory inventory fields. Select fields that drive a control, ownership or risk decision. Commonly useful fields include:

Field	Why it matters
Unique identifier	Prevents ambiguity and supports reconciliation
Asset name and description	Explains what the asset is and its business purpose
Asset category	Enables consistent handling and reporting
Business service or process	Shows operational impact and dependencies
Information classification	Connects handling rules to the asset
Accountable owner	Assigns authority for risk and acceptable use decisions
Operational custodian	Identifies who administers or maintains the asset
Location or hosting model	Supports physical, cloud and jurisdiction decisions
Lifecycle status	Distinguishes proposed, active, suspended and retired assets
Criticality or recovery need	Supports continuity and availability decisions
Supplier or contract reference	Connects external assets to supplier governance
Last verified date	Provides evidence that the entry is maintained

Avoid collecting fields that no one maintains or uses. A smaller inventory with clear ownership and dependable updates is stronger than a large register full of unknown values.

Separate ownership from custody

An asset owner is accountable for decisions about protection, access, acceptable use and risk. The owner does not need to administer the asset personally. A business process owner may own customer data while an infrastructure team operates the database and a cloud provider hosts it.

Document this separation explicitly:

• the owner approves classification, access principles and risk treatment;
• the custodian implements operational safeguards and maintains technical records;
• the user follows authorised-use requirements; and
• the supplier performs contracted activities under defined obligations.

Naming a department such as “IT” as owner for every item can hide business accountability. Prefer a durable role, such as Head of Customer Operations, rather than a person’s name alone. The role can remain stable when staff change.

Build discovery into operational processes

An annual manual review cannot reliably detect fast-moving cloud resources, SaaS subscriptions or endpoints. Combine periodic owner confirmation with event-driven and technical discovery.

Useful sources include:

• procurement and contract records;
• device and endpoint-management platforms;
• cloud account and resource inventories;
• network and vulnerability discovery;
• software repositories and deployment pipelines;
• identity directories and privileged-access platforms;
• data-flow and records-management work;
• joiner, mover and leaver activity;
• supplier onboarding and change notices; and
• service retirement and disposal records.

Reconcile these sources against the governed inventory. Exceptions should create an owned action: investigate an unknown resource, add a missing asset, correct stale ownership or retire an obsolete record.

The Annex A control lookup can help teams understand how asset records connect to controls for classification, access, supplier relationships, configuration and secure disposal.

Control the full lifecycle

Inventory quality depends on when records change. Define triggers for creation, review, transfer and closure.

Acquisition and creation

Before a new service, data set or system becomes operational, assign an owner, identify its purpose, determine classification and connect it to the relevant service. Where risk assessment is required, use the same identifier in both records.

Change and operation

Update the record when material characteristics change: owner, hosting region, supplier, classification, criticality, integration, purpose or lifecycle state. Technical discovery can identify configuration drift, but the business owner must decide whether the changed use remains acceptable.

Transfer and return

Role changes, contract expiry and worker departure should trigger return or reassignment of physical and logical assets. Evidence might include device return, access revocation, account transfer, repository ownership change and confirmation that local copies were removed where required.

Retirement and disposal

Retirement requires more than marking a row inactive. Confirm data migration or deletion, credential removal, contract closure, media sanitisation, disposal evidence and removal from monitoring, backup and access systems. Retain enough history to explain what happened.

Connect the inventory to risk and controls

The inventory is not the risk assessment, but it should make risk decisions traceable. A reviewer should be able to move from a critical service to its information, supporting assets, relevant risk scenarios and controls.

Use the ISO 27001 risk score calculator to test a consistent likelihood-and-impact method, then record the approved result in the organisation’s governed risk process.

Inventory relationships can also reveal concentration risk. Several services may depend on one identity provider, cloud region or specialist administrator. If each asset is assessed alone, the shared dependency may go unnoticed.

Evidence that design and operation both work

An auditor normally needs more than an exported register. Design evidence shows how the process should work; operating evidence shows that it does.

Design evidence may include:

• the defined asset categories and ownership model;
• required fields and lifecycle states;
• procedures for discovery, review, return and disposal;
• integration with procurement, change and offboarding; and
• criteria for criticality and classification.

Operating evidence may include:

• recent owner attestations and resolved exceptions;
• reconciliation results from cloud, endpoint or network sources;
• newly created assets with timely ownership;
• change records that updated inventory entries;
• returned devices and revoked accounts; and
• retired assets with deletion or disposal evidence.

For access governance, compare a sample of important assets with the controls described in the access-control evidence guide. For external services, trace ownership and lifecycle responsibilities into the supplier-security process.

Audit with risk-based sampling

A useful sample spans categories and lifecycle stages rather than selecting only convenient active servers. Include:

• a critical information set;
• a cloud service;
• a user endpoint;
• an externally provided service;
• a recently introduced asset;
• an asset that changed owner or classification; and
• a retired or returned asset.

For each sample, verify the record against an independent source, confirm the owner understands the role, trace the asset to relevant risks and controls, and inspect evidence of its current lifecycle state.

Results can be assessed as follows:

• Effective: important assets are discoverable, owned, connected to services and maintained through lifecycle events.
• Partially effective: a register exists, but some categories, owners or change triggers are unreliable.
• Ineffective: records are materially incomplete or stale, and risk or control decisions cannot be traced to the assets concerned.

Keep the inventory decision-ready

Measure qualities that reveal whether the process works: unassigned ownership, overdue confirmations, discovered-but-unrecorded assets, unresolved reconciliation exceptions and retirement records awaiting closure. Report trends and causes, not only the total number of rows.

An effective inventory is a maintained map of what the organisation relies on. When it connects services, information, supporting assets, owners and lifecycle evidence, it becomes useful for everyday decisions and credible in an audit.

The subject was cross-checked against the ISO/IEC 27001 overview. The field set and audit method above are AuditPrepared guidance, not prescribed ISO wording.