Implementing ISO 27001 Annex A 5.9 is the strategic foundation of identifying, classifying, and managing a comprehensive Inventory of Assets to ensure complete visibility over the organization’s attack surface. It requires establishing specific ownership for every hardware, software, and data component, enabling effective risk treatment and preventing security gaps caused by Shadow IT or unmanaged resources.
ISO 27001 Annex A Inventory of information and other associated assets Implementation Checklist
Use this implementation checklist to achieve compliance with ISO 27001 Annex A 5.9. Compliance with this control requires a comprehensive, verified list of every hardware, software, and data asset you own, managed in a dynamic register rather than a static GRC placeholder.
1. Establish the Master Asset Register
Control Requirement: An inventory of information and other associated assets, including owners, shall be developed and maintained.
Required Implementation Step: create a centralized ‘Master Asset Register’ using a high-availability spreadsheet (Excel/CSV) or a dedicated IT Asset Management (ITAM) database like Snipe-IT. Do not rely on the ‘Assets’ module of a GRC tool unless it dynamically syncs with your infrastructure. Define columns for: Asset ID, Type, Description, Owner, Location, Classification, and Status.
Minimum Requirement: A single source of truth file named master-asset-register.xlsx stored in a restricted access folder.
2. Execute a Physical Hardware Audit
Control Requirement: All physical assets must be identified.
Required Implementation Step: Physically walk the floor and audit the server room. Verify that every laptop, server, firewall, and switch has a unique Asset Tag sticker. Cross-reference this physical check against your purchasing records (invoices). If you are remote, require staff to submit a photo of the asset tag on the back of their company-issued laptop.
Minimum Requirement: A completed stocktake log comparing physical serial numbers to purchase orders.
3. Perform Automated Network Discovery
Control Requirement: Assets connected to the network must be identified.
Required Implementation Step: Run a network scan (using tools like Nmap, Lansweeper, or OpenVAS) to identify every IP address on your subnet. Identify ‘rogue’ devices that appear on the network but are not in your Master Asset Register. Investigate and document them immediately.
Minimum Requirement: A network scan report showing 100% correlation between active IP addresses and the Asset Register.
4. Audit Cloud Resources via API/Tagging
Control Requirement: Virtual assets must be included in the inventory.
Required Implementation Step: Log in to your Cloud Service Provider (AWS, Azure, GCP). Export a list of all active instances, buckets, and databases. Implement a mandatory ‘Tagging Policy’ where every resource must have an ‘Owner’ and ‘Project’ tag. Untagged resources should be flagged for termination.
Minimum Requirement: A script or report listing all cloud resources and their assigned owners.
5. Uncover Shadow IT via Financial Records
Control Requirement: Information assets (including SaaS) must be identified.
Required Implementation Step: Request the last 12 months of company credit card statements and expense reports from the Finance Director. Filter for software vendors (e.g., ‘Dropbox’, ‘Canva’, ‘Slack’). Add these SaaS accounts to the Asset Register. This is the only way to find Shadow IT that the IT department is unaware of.
Minimum Requirement: A list of SaaS subscriptions derived solely from financial transaction data.
6. Assign Specific Human Owners
Control Requirement: Assets must have a designated owner.
Required Implementation Step: Assign a named individual (not a department) to every line item in the register. The ‘Owner’ is the person responsible for the asset’s security and lifecycle, typically the head of the department using the software or the engineer managing the server. ‘IT Support’ is not an owner; ‘John Smith, SysAdmin’ is.
Minimum Requirement: The Asset Register must not contain any generic group names (e.g., “Marketing”) in the “Owner” column.
7. Classify Information Assets
Control Requirement: Assets must be classified in terms of their value and sensitivity.
Required Implementation Step: For every data asset (databases, file shares, hard copies), assign a classification label based on your Information Classification Policy (e.g., Public, Internal, Confidential). Add a ‘Classification’ column to your register and populate it. This dictates how the asset must be handled.
Minimum Requirement: Every information asset in the register has a classification level assigned.
8. Map Information to Containers
Control Requirement: Understand where information is stored.
Required Implementation Step: Create a data flow map or a simple link in the register connecting ‘Information’ to ‘Hardware/Software’. For example, document that the ‘Customer CRM Database’ (Information Asset) resides on ‘AWS RDS Instance #44’ (Hardware Asset). If you lose the hardware, you must know what data is at risk.
Minimum Requirement: A demonstrated link between critical data sets and the infrastructure that hosts them.
9. Define Asset Return Procedures
Control Requirement: Assets must be returned upon termination of employment.
Required Implementation Step: Update the Employee Offboarding Checklist. It must explicitly list the hardware (laptop, phone) and logical assets (SaaS accounts, API keys) that must be returned or revoked. The manager must sign off that all items listed in the Asset Register for that employee have been recovered.
Minimum Requirement: A signed “Return of Assets” form for the most recent leaver.
10. Schedule Quarterly Asset Reconciliations
Control Requirement: The inventory must be maintained and reviewed.
Required Implementation Step: Do not let the register rot. Schedule a quarterly meeting where Department Heads review their specific section of the Asset Register. They must confirm: “Do you still use this?” and “Is this person still the owner?”. Archive or dispose of assets that are no longer verified.
Minimum Requirement: Evidence of a quarterly review (email confirmation or meeting minutes) updating the register.
ISO 27001 Annex A 5.9 SaaS / GRC Platform Implementation Failure Checklist
| Control Requirement | The ‘Checkbox Compliance’ Trap | The Reality Check |
|---|---|---|
| Dynamic Inventory | GRC tools require you to manually type asset details into a web form. | Failure: Manual entry is obsolete the moment you click save. Real compliance requires automated discovery tools (Lansweeper, AWS Config) that export to CSV, not manual data entry. |
| Shadow IT Discovery | The tool offers a “Software Asset” tab to list approved apps. | Failure: The tool only lists what you know about. It cannot scan your credit card ledger to find the 40 unauthorized Trello accounts your marketing team paid for. |
| Ownership Assignment | Allows assigning “Admin” or “HR Team” as owners. | Failure: When a server is breached, a “Team” cannot take responsibility. You need a specific human name. GRC tools rarely enforce this granularity. |
| Cloud Integration | “Cloud Asset Module” available for an extra $5k/year. | Failure: You can get better visibility for free using the native export tools of AWS/Azure. The GRC module is often just a shallow, non-real-time mirror. |
| Data Mapping | Generic high-level logic (e.g., “We have customer data”). | Failure: You need to know that “Customer Data Table v2” is on “Server-01”. GRC tools struggle to map specific data sets to specific infrastructure assets effectively. |
| Asset Return | A checkbox saying “Asset Returned” on the user profile. | Failure: You need a signed handover form and a log of access revocation. A checkbox is not evidence; a ticket number from your Service Desk is. |
| Lifecycle Management | Static lists that grow indefinitely. | Failure: GRC tools rarely prompt you to delete or dispose of old assets. This leads to a bloated register full of ghosts that no longer exist, failing the accuracy requirement. |
DO IT YOURSELF ISO 27001
STOP SPANKING £10,000s on CONSULTANTS and ISMS ONLINE PLATFORMS
About the author
