ISO 27001 A.5.9: Build an Inventory That Supports Security Decisions

What A.5.9 requires in practice

Annex A control A.5.9 asks the organisation to compile and keep up to date a register of information and the other assets associated with it, including their owners. Two parts stand out. The inventory must cover information itself as well as the things that hold or process it, such as systems, services, devices and sometimes people or locations. And each item must have an owner who is accountable for it.

The organisation decides the level of detail and how assets are grouped. A group of similar devices or a category of records can be treated together if that supports sound decisions. Maintaining means the inventory stays accurate as assets are added, changed and retired.

The control does not require a specific tool or format. A spreadsheet, a service catalogue or a configuration database can all serve if they are reliable. What matters is that the organisation knows what it needs to protect and who answers for it.

Start from information and the work it supports

Identify important business information and follow where it is created, used, stored and transferred. Then examine the services, systems, equipment and external relationships that support it. This approach can expose assets that an equipment scan will miss, such as an archive held by a provider or information retained in an acquired business process.

Choose a useful level of detail. Grouping similar information can be appropriate when ownership and protection needs are clear. More detail is warranted when separate assets have materially different risks or responsibilities. Cataloguing every transient file individually may create an unmaintainable list without improving decisions.

Make ownership a working responsibility

An owner should be able to make or obtain decisions about the asset’s protection and lifecycle. This may differ from the person maintaining the technology. A business owner can define the importance and permitted use of information, while a technical custodian implements agreed arrangements.

Assign ownership when assets or information enter the organisation and reconsider it when people or services change. “IT” is often too broad to resolve a contested access or disposal decision. Where ownership belongs to a group, define how the group reaches an authorised decision. Connect these arrangements with security responsibilities.

Use linked inventories without creating competing truths

Existing equipment, application, supplier and information records can support the control. They need not become one enormous table. Establish how related records connect and which source is authoritative for each important item. If a service owner changes, identify which dependent records need updating.

Automated discovery can contribute evidence about some technical assets, but it does not automatically identify business importance, contractual responsibility or every externally hosted resource. Compare discovery results with procurement, service and operational knowledge. Unexplained differences are questions to investigate rather than entries to delete for a cleaner dashboard.

Why an asset inventory matters to the business

It is hard to protect what nobody knows exists. An accurate inventory underpins risk assessment, access decisions, incident response, supplier management and disposal. Without it, forgotten systems remain unpatched, sensitive information sits in unexpected places and nobody feels responsible when something fails.

Owners matter as much as the list. When a named person answers for an asset, decisions about classification, access and retention have somewhere to go. For customers and assessors, a credible inventory shows that scope and risk are based on facts. A stale list, however long, gives false comfort and tends to be exposed quickly in sampling.

How to implement A.5.9

Start with what supports your most important services and information, then widen as the practice proves its worth. The best way to keep this manageable is to attach inventory updates to events that already occur, rather than a separate yearly exercise. Treat the first version as a working draft that improves each time it is checked against real systems and teams.

1. Decide which kinds of asset belong in the inventory, covering information, systems, services, devices and relevant third-party holdings.
2. Choose a level of grouping that supports decisions without becoming impossible to maintain.
3. Collect assets from existing sources such as procurement, IT management tools, project records and interviews with teams.
4. Assign an owner to each item or group, and check that the owner understands the role.
5. Build updates into events that already happen, such as onboarding a system, a purchase or decommissioning.
6. Reconcile the list against reality at intervals, looking for assets that exist but are unlisted.
7. Use the inventory as an input to risk assessment and classification.

Evidence an auditor expects for A.5.9

Common nonconformities with A.5.9

Findings generally point to a list that has decayed or has no real owners. Assessors frequently find that the inventory looks complete until they trace something found in the environment.

• Assets found during the audit are missing from the inventory.
• Entries show no owner, or an owner who has since left the organisation.
• Information assets are not covered, so only hardware and software appear.
• The inventory is created for the audit and not used or updated afterwards.
• Owners are listed, but they are unaware of the assets they are assigned or the responsibilities that follow.

Illustrative BPO example: an overlooked recording archive

Illustrative manufacturing example: process information ownership

A hypothetical manufacturer records the computers supporting a production line but has not assigned ownership of the process recipes and their approved versions. Engineering maintains the files, production relies on them and quality staff approve changes, leaving protection decisions fragmented.

The company identifies the information set and its supporting systems, agrees decision responsibilities and links it to the affected production service. It examines integrity and availability as well as confidentiality. The inventory now helps determine who must be involved when a change or recovery affects the recipes.

Maintain the view when assets change

Connect updates with acquisition, introduction, transfer, significant change and retirement. Periodic reconciliation can detect gaps that those triggers miss. Select review effort according to volatility and consequence: a rapidly changing cloud environment may need a different approach from a stable physical archive.

Use a practical test in both directions. Select an item in the inventory and locate its real owner and use; then select something observed in operations and trace it back to the inventory. Include a provider service or recently retired asset. This tests both accuracy and completeness, rather than confirming that known rows exist.

Evidence includes the inventory itself, ownership and useful maintenance records. Specific fields beyond the necessary outcome are design decisions. Common failures include departed owners, inventories maintained solely for insurance and records that ignore dependencies. Link the inventory to information classification so that identified assets have meaningful protection needs rather than only identifiers.