For Annex A control 5.9, "Inventory of information and other associated assets", an inventory is a maintained list with a named owner per asset. For software teams, repositories, deployed services, cloud accounts and SBOM component lists can all feed it, as long as someone reviews the list on a schedule and the review is recorded.
What the control title tells you
ISO/IEC 27001:2022 Annex A has 93 controls in four themes: 37 organizational, 8 people, 14 physical and 34 technological. Control 5.9 sits in the organizational theme and is titled "Inventory of information and other associated assets". The title names two things: information, and the assets that hold or process it.
Annex A controls are reference controls. You pick the ones that apply through your risk assessment and record the choice in your Statement of Applicability, so 5.9 is rarely optional in practice but the depth is your call. The exact wording of the control sits in the standard, which you should read before you design evidence. This post only covers how engineering artifacts can feed the list.
Which engineering sources can feed the inventory
Think in layers. Each layer answers a different question an assessor might ask.
| Layer | Example source | Fields worth keeping |
|---|---|---|
| Code | Repository list from your source host | Name, owner team, visibility, last activity |
| Running software | Service catalog or deployment manifests | Service name, environment, owner, data class |
| Components | SBOM per release | Package name, version, source, license |
| Infrastructure | Cloud account and resource export | Account, region, resource type, tag owner |
| Information | Data store list | System, data classification, retention owner |
None of these is the inventory by itself. The inventory is the joined, owned and reviewed list. A raw export with no owner column is a data dump, and an assessor can fairly ask who is accountable for each row.
Steps to build it without a new spreadsheet empire
- Pick one system of record per layer. A source host for repos, a catalog for services, a registry for images.
- Add an owner field and make it mandatory. Unowned assets are the first thing to chase.
- Export on a schedule, for example monthly, and store the dated export in an evidence folder.
- Compare each export with the last one. New and removed assets are the interesting rows.
- Record the review: who looked, when, and what changed. A short ticket or a signed off pull request works.
- Link the classification of information to the asset, so the "information" half of the title is covered too.
Keep the process small enough that it survives a busy quarter. A monthly diff that someone actually reads beats a perfect quarterly rebuild that nobody has time for.
Gaps worth checking in your own list
Forks and archived repos that still hold secrets or deploy keys. Services started in a personal cloud account. Container images that run in production but are not in any catalog. Vendor SaaS tools that hold customer data. Each is a place where the inventory and reality drift apart.
Also check that the same asset has one name across sources. A repo called billing-api, a service called payments and an image called bapi may be the same thing, and your list should say so.
Try it yourself
Click through the dependency inventory and notice how each component lists a version and a source. That is the component layer of an inventory, ready to be tied to an owner.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard can produce SBOM and dependency scanning results and run asset discovery, which gives you machine generated inventory records to attach next to your own review notes. You can try the free scan at gold.safeguard.sh/scan. Whether a record satisfies a control is for you and your auditor to decide.
Quick check
Is an SBOM the same as an asset inventory?
No. An SBOM lists the components inside one piece of software. An asset inventory is wider and covers repositories, services, infrastructure and information. SBOMs feed the component layer of it.
How often should the inventory be reviewed?
The control title does not set a number. Choose a cadence that matches how fast your estate changes, write it in your procedure, and keep dated review records so you can show you followed it.
Sources
- ISO 27001 Annex A controls list, Security Compliance Guide
- ISO 27001 Annex A controls explained, Glocert International
Last reviewed: 19 October 2026.
