Annex A Controls

A.5.9 and A.5.10 — Asset Inventory and Acceptable Use

Alex Fuerst

09 Sep 2025 — 7 min read

The Foundation That Makes or Breaks Your ISMS

Every organization I audit claims they have an asset inventory. About 20% actually have something useful. The rest have either a dusty spreadsheet last updated when someone remembered it existed, an automatically generated list from a scanning tool that nobody reviews, or my personal favorite: a SharePoint site with 47 different versions of "Asset_List_FINAL_v3_UPDATED.xlsx" and no indication which one is current.

Controls A.5.9 (Inventory of Information and Other Associated Assets) and A.5.10 (Acceptable Use of Information and Other Associated Assets) are foundational. Get them wrong, and your entire ISMS is built on sand. You cannot protect what you don't know you have, and you cannot expect people to handle assets properly without telling them what "properly" means.

These controls underwent significant revision in the 2022 update, expanding from the narrow IT focus that characterized the 2013 version. The standard now explicitly recognizes that information security extends far beyond servers and laptops to encompass all assets that create, process, store, or transmit information—including intangible assets like reputation and brand value.

Understanding What A.5.9 Actually Requires

The control text states that "an inventory of information and other associated assets, including owners, should be developed and maintained." Simple enough on paper. In practice, this control trips up organizations constantly because they misunderstand what "information and other associated assets" actually means in 2022.

The revised standard intentionally broadened this beyond traditional IT assets. Your inventory must encompass:

Information assets — databases, data files, contracts, system documentation, research information, user manuals, training materials, operational procedures, business continuity plans, audit trails, archived information
Physical assets — computer equipment, communications equipment, removable media, other technical equipment, facilities, buildings
Software assets — application software, system software, development tools, utilities
Services — computing and communications services, utilities (heating, lighting, power, air conditioning)
People and competencies — their qualifications, skills, and experience
Intangibles — reputation, brand, intellectual property

I once audited a financial services firm that had invested heavily in an IT asset management tool. Their inventory of servers, workstations, and network equipment was exemplary. When I asked about their information assets—the actual data those systems processed—they looked at me like I'd asked them to explain quantum physics. They had no documented inventory of customer data repositories, transaction records, or even which systems held what categories of sensitive information. Their IT asset inventory was excellent. Their information asset inventory was nonexistent.

The Granularity Challenge

ISO 27002 guidance recognizes that inventory granularity should be "at a level appropriate for the needs of the organization." This means you don't need to track every temporary file or short-lived virtual machine instance. But you do need to capture assets at a level that supports meaningful risk assessment and security decisions.

For cloud environments, this becomes particularly relevant under ISO 27017 guidance. Your inventory should distinguish between Infrastructure as a Service (IaaS) components you control versus Platform as a Service (PaaS) elements managed by your provider. A common mistake I see is organizations trying to inventory every container instance in a dynamic Kubernetes cluster—that's not practical or necessary. Instead, focus on the applications, data flows, and persistent storage that represent actual business risk.

The Ownership Problem That Kills Accountability

A.5.9 specifically requires that owners be identified. This is where I see the most compliance theater. Organizations assign ownership in one of two dysfunctional ways:

The IT Department Owns Everything: Every asset gets assigned to "IT" or the CIO. This satisfies the checkbox but provides zero accountability. When a data breach occurs involving customer information, who's responsible? IT doesn't own the customer relationship. They don't decide what data to collect, how long to retain it, or who should have access. IT are custodians, not owners.

Nobody Owns Anything: The ownership field exists but contains entries like "TBD," "Various," or names of people who left the company years ago. I've seen inventories where 40% of assets were owned by former employees.

Proper ownership under the 2022 standard means identifying someone who:

Has authority to make decisions about the asset's use and access
Understands its business value and sensitivity classification
Can approve who accesses it and under what circumstances
Is accountable for ensuring appropriate protection measures
Reviews classification and protection requirements periodically

For a customer database, the owner should be someone from the business side—perhaps the Head of Customer Services or a Data Governance manager—not the database administrator. The DBA is a custodian with technical responsibilities, but they don't own the information or make business decisions about it.

Making Your Inventory Support Business Decisions

An asset inventory that exists only to satisfy auditors is waste. A useful inventory supports actual security decisions and integrates with your broader ISMS processes.

Integration with Risk Assessment

Your asset inventory should feed directly into your risk assessment process (Clause 6.1.2). Every asset in your ISMS scope should have associated risks identified and treatment plans assigned. If your inventory lives in one system and your risk register lives in another with no connection between them, you're maintaining compliance documentation, not managing security.

During audits, I test this integration by selecting assets from the inventory and asking to see their associated risk assessments. Organizations with mature ISMS can demonstrate this linkage immediately. Those practicing compliance theater scramble to explain why their "critical" assets have no identified risks.

Clear Scope Boundaries

Not every asset in your organization needs to be in your ISMS inventory. Your ISMS has a defined scope (Clause 4.3), and your inventory should reflect only those assets within that scope or that support in-scope activities. A manufacturing company might exclude their cafeteria equipment but include their research and development databases—even if both are technically "organizational assets."

Classification Alignment

The 2022 revision explicitly requires that "each asset should be classified in accordance with the classification of the information associated to that asset." This creates a direct dependency on Control 5.12 (Classification of Information). Your inventory isn't complete without classification levels that reflect the sensitivity of information each asset handles.

A.5.10: Beyond "Don't Use Facebook at Work"

Control A.5.10 requires that "rules for the acceptable use and procedures for handling information and other associated assets should be identified, documented and implemented." Most organizations interpret this as needing an "Acceptable Use Policy" that prohibits social media and personal email. That's thinking small.

The 2022 revision emphasizes acceptable use across the full information lifecycle, aligned with asset classification levels. Your acceptable use framework should address:

Access restrictions that correspond to classification levels and business need
Handling procedures for different asset types and sensitivity levels
Storage requirements that consider asset protection needs
Transmission controls for sharing information internally and externally
Retention and disposal procedures that ensure secure destruction
Monitoring activities and the extent of organizational oversight

Third-Party and Cloud Assets

The guidance specifically notes that assets "concerned do not directly belong to the organization, such as public cloud services." Your acceptable use procedures must address how staff interact with third-party platforms, Software as a Service applications, and collaborative tools. This connects directly to ISO 27017 for cloud security and ISO 27036 for supplier relationship security.

I frequently see organizations that have excellent acceptable use policies for their internal systems but no guidance for cloud platforms. Staff default to personal cloud accounts for file sharing, creating information security gaps that bypass all internal controls.

What the Auditor Looks For

During audits of these controls, I examine specific evidence:

For A.5.9 Asset Inventory:

Documented inventory that covers all asset types within ISMS scope
Clear asset owners identified with contact information and role descriptions
Asset classification levels aligned with information classification scheme
Regular review processes with evidence of updates and accuracy checks
Integration points with risk assessment and incident response processes
Location information for physical and logical assets

For A.5.10 Acceptable Use:

Comprehensive acceptable use policy covering all asset types and classifications
Evidence that policy has been communicated to all relevant personnel
Specific procedures for handling different classification levels
Clear consequences for policy violations
Regular policy review and update processes
Monitoring capabilities and oversight procedures

The most common deficiency I find is disconnection between these controls and the broader ISMS. Organizations treat them as standalone requirements rather than foundational elements that support risk management, incident response, and continuous improvement.

Common Implementation Mistakes

Based on hundreds of audits, here are the mistakes that consistently undermine these controls:

Inventory as IT Asset Management: Focusing only on hardware and software while ignoring information assets, people competencies, and intangible assets. The 2022 revision made this approach non-compliant.

Static Documentation: Creating inventories and acceptable use policies as point-in-time documents that never get updated. These must be living documents that reflect organizational changes.

Generic Acceptable Use Policies: Implementing template policies that don't address your specific assets, classification scheme, or business context. Your acceptable use procedures should be as unique as your organization.

No Integration with Other Controls: Treating A.5.9 and A.5.10 in isolation rather than as foundational controls that support access control (A.9), cryptography (A.10), incident management (A.16), and supplier management (A.15).

Building Sustainable Practices

Sustainable implementation of these controls requires embedding them into business processes rather than treating them as compliance overhead. Asset inventory updates should happen automatically when systems are provisioned or decommissioned. Acceptable use training should be part of onboarding and regular security awareness programs.

Organizations that get this right often leverage their Configuration Management Database (CMDB) systems, identity management platforms, and data governance tools to maintain accurate inventories with minimal manual effort. They build acceptable use requirements into procurement processes, ensuring third-party tools meet security standards before deployment.

Remember that these controls scale with your organization. A small business might maintain asset inventory in a simple spreadsheet, while an enterprise needs automated discovery and tracking tools. What matters is accuracy, completeness, and integration with your security management processes.

Controls A.5.9 and A.5.10 aren't just compliance requirements—they're the foundation that makes every other security control possible. Get them right, and your ISMS has solid footing for managing risk and protecting information. Get them wrong, and you're building security theater that won't survive real-world threats.

Need implementation guidance specific to your organization? Connect with experienced practitioners and get practical advice at the IX ISO 27001 Info Hub, or consider a consultation to review your current asset management and acceptable use frameworks.

Need personalized guidance? Reach our team at ix@isegrim-x.com.