ISO 27001 Control 5.9: Inventory of Information and Other Associated Assets

When incident response kicks off and nobody can answer “what systems do we actually have?”, the investigation stalls before it starts. Risk assessments built on incomplete asset inventories produce false confidence — gaps you can’t see become gaps you can’t protect. Control 5.9 is the foundation that every other ISO 27001 control depends on: you cannot secure what you haven’t inventoried.

What 5.9 Requires

ISO 27001 Annex A 5.9 requires your organization to build and maintain a complete inventory of all information and associated assets — and keep it accurate over time.

In practical terms, that means three things:

Identify and record every asset. The scope is deliberately broad. “Information and other associated assets” covers information assets (databases, files, contracts, intellectual property), physical assets (servers, laptops, removable media, networking equipment), software (licensed applications, custom-built tools, SaaS subscriptions), cloud resources (virtual machines, storage buckets, serverless functions, platform services), and the people whose competencies are critical to operating those assets. If it stores, processes, or transmits information — or if losing it would impact operations — it belongs in your inventory.

Assign a named owner to every asset. Not a department, not a team alias — a specific individual who is accountable for that asset’s classification, protection, and lifecycle. The owner doesn’t need to personally manage day-to-day operations (that role often falls to a custodian), but they must be the decision-maker for how the asset is classified, who can access it, and when it should be decommissioned. When ownership is ambiguous, accountability disappears — and unaccountable assets are unprotected assets.

Keep the inventory current. An asset register that was accurate six months ago is not accurate today. Infrastructure changes constantly — new cloud instances spin up, employees join and leave, SaaS contracts start and expire, hardware gets retired. The standard expects your inventory to reflect acquisitions, transfers, changes in classification, and decommissions as they happen, not once a year during audit prep. Each entry should record the asset’s identifier, type, owner, location (physical or logical), classification level, custodian (if different from the owner), and its relationship to other assets in the environment.

The core rationale is straightforward: you cannot assess risk against assets you don’t know exist, you cannot respond to incidents involving systems you haven’t documented, and auditors will flag an incomplete inventory as a nonconformity every time.

Why 5.9 Matters

Consider a scenario that plays out more often than most organizations admit: during incident response, the team discovers a production database that was never added to the asset register. It has no assigned owner. Nobody classified its contents, so it was never included in vulnerability scanning or patch management. It has been running unpatched for months, exposed to the network, holding customer records that should have been encrypted at rest.

This is not a hypothetical edge case. According to Trend Micro’s 2025 research, 74% of organizations have experienced security incidents directly caused by unknown or unmanaged assets. The pattern is predictable: when an asset is missing from the inventory, it is missing from classification. When it is missing from classification, it receives no risk treatment. When it receives no risk treatment, it gets no protection. Every downstream control — access management, vulnerability management, encryption, monitoring — assumes it has a complete picture of what exists. Control 5.9 is the control that makes that picture possible.

From a risk perspective, 5.9 is a foundational control failure when it breaks. Its severity is high not because of what it does in isolation, but because every other control in your ISMS depends on the accuracy of your asset inventory. Access control policies reference assets. Vulnerability scanning targets assets. Encryption policies apply to classified assets. Incident response playbooks triage by asset criticality. If the inventory feeding all of those processes is incomplete, every downstream decision is built on a false premise. A gap here cascades into gaps everywhere.

What attackers exploit

Incomplete asset inventories create specific, exploitable blind spots:

• Untracked cloud instances running outside the security team’s visibility, with no hardening baseline, no monitoring, and default credentials still active.
• Shadow IT — SaaS tools purchased by business units with a credit card, processing company data with no security review and no contractual protections.
• Orphaned assets left behind when employees depart, with active credentials and no decommission process to revoke access or reassign ownership.
• Unpatched systems that were never enrolled in vulnerability scanning because they were never added to the asset register in the first place.
• Unclassified data stores receiving no encryption, no access controls, and no retention policies because nobody documented what they contain.
• Physical assets — laptops, external drives, backup tapes — with no location tracking, making it impossible to confirm whether they’ve been lost, stolen, or disposed of securely.

How to Implement 5.9

For your organization (first-party)

The cost of getting this wrong is well documented. IBM’s Cost of a Data Breach research found that 35% of breaches involved data stored in unmanaged sources — what they call “shadow data” — assets that exist outside the organization’s inventory and governance. Effective implementation of 5.9 is about closing those gaps before they become incidents.

Start by defining your asset categories. ISO 27002 guidance suggests five: information assets (data, records, documentation), physical assets (hardware, infrastructure), software assets (applications, licenses), cloud and virtual assets (IaaS/PaaS/SaaS resources, virtual machines, containers), and people (competencies and roles tied to asset operation). Getting these categories agreed upon early prevents the “is a SaaS subscription a software asset or a cloud asset?” debates that stall implementation.

Next, choose your inventory tooling based on scale. A small organization with a few dozen assets can maintain a structured spreadsheet with disciplined ownership. Mid-size organizations typically need a configuration management database (CMDB) or IT asset management (ITAM) platform. Larger or cloud-heavy environments should layer in cloud security posture management (CSPM) for auto-discovery of internet-facing assets and mobile device management (MDM) for endpoint tracking.

For each asset, record at minimum: asset ID, name, type, owner (named individual), custodian, location (physical or logical), classification level, and lifecycle status (active, archived, pending decommission).

Assign ownership at the point of creation — not retroactively during audit prep. Tie ownership assignment to your procurement and onboarding workflows so it happens automatically: when a new server is provisioned, a new SaaS contract is signed, or a new database is created, the owner is designated before the asset goes live. Procurement should not complete without an owner field populated. Cloud provisioning templates should require an owner tag. If you’re building the inventory for the first time, treat the backfill as a focused project with a deadline, but then shift immediately to a process where new assets never enter the environment without being registered.

Establish update triggers that keep the inventory alive: new asset acquisition triggers an addition, employee departure triggers a review and reassignment of their owned assets, infrastructure changes trigger reconciliation, and a full inventory review runs at least annually. Link the inventory to your classification scheme (per control 5.12) and feed it into your risk register so that risk assessments always operate on current data.

Common mistakes to avoid:

• Treating the inventory as a one-time certification project instead of a living process
• Inventorying hardware but ignoring information and data assets
• Assigning ownership to departments or distribution lists instead of named individuals
• Excluding cloud and SaaS assets because “IT doesn’t manage those”
• Building the inventory in isolation from risk assessment and classification workflows

For your vendors (third-party assessment)

When assessing vendors against 5.9, focus your questions on whether they have a functioning process — not just a document.

Questions to ask:

• “Do you maintain a complete inventory of assets that process, store, or transmit our data?”
• “How frequently is the asset inventory reviewed and reconciled?”
• “Who is responsible for asset classification, and how is ownership assigned?”

Evidence to request:

• Asset management policy (current version, with review date)
• Sample asset register (redacted to remove sensitive details, but showing structure, ownership fields, and classification)
• Evidence of periodic review — meeting minutes, reconciliation logs, or automated audit trails showing the inventory is actively maintained

Red flags that indicate weak implementation:

• The vendor cannot describe their asset categories or what “information assets” means in their context
• The inventory is a static spreadsheet with a “last modified” date older than 12 months
• No named asset owners — ownership is assigned to teams or left blank
• Cloud assets are explicitly excluded from the inventory scope
• The vendor’s ISO 27001 certificate scope does not cover the services they provide to you

Verification: Request the relevant sections of their SOC 2 Type II report covering asset management controls. Cross-reference their ISO 27001 certificate scope with the services they deliver — if the certificate covers only their headquarters but they process your data in a cloud environment, the inventory may not cover your assets. Pay particular attention to whether the vendor’s asset management practices extend to subprocessors: if they outsource infrastructure to a cloud provider, their inventory should account for how those shared-responsibility assets are tracked and owned.

Audit Evidence for 5.9

When preparing for an audit, your auditor will look for specific artifacts that demonstrate both the existence and the ongoing maintenance of your asset inventory. The table below covers the evidence types you should have ready.

Auditors will check that these artifacts are consistent with each other and that the review cadence described in your policy matches the actual review logs you produce. Expect them to select a sample of assets from the register and verify that the recorded details (owner, location, classification) match reality. They will also look for evidence that the inventory is integrated into broader ISMS processes — for example, that assets in the register are reflected in risk assessments and that newly provisioned assets are added promptly rather than discovered during the audit itself.

Cross-Framework Mapping

If your organization operates under multiple compliance frameworks, 5.9 maps cleanly to asset management requirements elsewhere. The table below shows the primary equivalences.

Organizations already compliant with CIS Controls 1 and 2 or NIST CM-08 will find significant overlap with 5.9’s requirements — in many cases, the same asset register and ownership records can serve both frameworks with minimal adaptation. SOC 2 CC6.1 provides partial coverage: it addresses logical and physical access controls that depend on knowing what assets exist, but it does not explicitly require a standalone comprehensive asset inventory or named ownership assignments. DORA’s Article 8 is particularly relevant for financial services organizations operating in the EU, as it mandates ICT asset identification and classification in terms that closely mirror 5.9. If you maintain a single well-structured inventory with ownership, classification, and lifecycle tracking, you can satisfy the asset management requirements across all five frameworks from one source of truth.

Related ISO 27001 Controls

Control 5.9 sits at the center of a cluster of asset-related controls. Understanding these connections helps you implement 5.9 in a way that supports the broader ISMS.

Frequently Asked Questions

What is ISO 27001 5.9? ISO 27001 Annex A 5.9 is the control that requires organizations to identify, record, and maintain a complete inventory of all information and associated assets, with a named owner assigned to each. It is a foundational control that supports risk assessment, incident response, and every other security control in the ISMS.

What happens if 5.9 is not implemented? Without a functioning asset inventory, your organization cannot accurately assess risk, apply consistent security controls, or respond effectively to incidents. Auditors will raise a nonconformity, which can block or delay certification. Over time, untracked assets accumulate as unmanaged attack surface, and the gap between your documented security posture and your actual exposure grows wider with every unregistered asset.

How do you audit 5.9? Auditors verify 5.9 by reviewing the asset management policy, examining the asset register for completeness and accuracy, confirming that every asset has a named owner, and checking reconciliation logs to ensure the inventory is actively maintained. They will also test a sample of assets to confirm the register matches reality.

How UpGuard Helps

Gain complete visibility into your asset landscape.

UpGuard’s platform provides continuous monitoring and inventory visibility across your vendor ecosystem, helping you maintain the asset awareness that control 5.9 demands. Identify unmanaged exposures, track vendor security posture in real time, and keep your risk assessments grounded in accurate, current data.

Explore the UpGuard Platform →