The auditor asks for your asset register. You send them a spreadsheet. The spreadsheet has 847 rows, was last updated in November, and the person who maintained it left the company in January. Three of the columns are labelled “TBD.” One tab is called “OLD — do not use.” The auditor writes a finding.
This scenario plays out in organisations of every size, across every industry. Not because the companies don’t care about ISO 27001 Annex A.8 — they do. But because the way most teams implement an asset inventory is fundamentally incompatible with how assets actually behave.
What Annex A.8 Actually Requires
ISO 27001:2022 Annex A.8 — Information Asset Management — sets out three core requirements:
A.8.1: Inventory of assets. Assets associated with information and information processing facilities shall be identified and an inventory of these assets shall be drawn up and maintained.
A.8.2: Ownership of assets. Assets in the inventory shall have an owner.
A.8.3: Acceptable use of assets. Rules for the acceptable use of, and procedures for handling, information and other associated assets shall be identified, documented, and implemented.
The keyword is maintained. Not created. Not submitted. Maintained — as in, current, accurate, and updated as assets change state.
A spreadsheet is a creation tool. It is not a maintenance tool. The moment you close the file, the inventory begins drifting from reality.
The Hardware Problem Is Worse Than the Software Problem
Software assets — SaaS subscriptions, licenses, cloud instances — at least have APIs. You can query them. You can pull a fresh list from Okta, from your cloud billing account, from your endpoint management system. The data is retrievable because the software was designed to be queried.
Hardware doesn’t work that way. Laptops don’t announce themselves. Servers don’t update a central registry when they move from the data centre to a co-location facility. USB drives don’t log ownership transfers.
Hardware inventory is fundamentally a manual discipline, which makes it uniquely vulnerable to the force that destroys all manual processes: people getting busy.
Here is what actually happens:
- A new laptop is procured. Procurement knows. IT knows. Finance knows. Nobody updates the asset register.
- An employee returns their device when they leave. The device goes back into the pool. The register still shows it assigned to the former employee.
- A server is decommissioned. It goes off the network. The register still shows it as active. For years.
- An office relocates. Physical location data across the entire register becomes wrong overnight.
After eighteen months of this, your ISO 27001 asset register contains a blend of current assets, historical assets, ghost assets, and assets that were never recorded in the first place. The blend is indistinguishable without doing physical spot-checks against the register — which is the audit finding you were trying to avoid.
What Auditors Are Actually Looking For
When an ISO 27001 auditor reviews your asset register, they are not looking for a count of how many laptops you own. They are testing three things.
Completeness. Does the register include assets that are not in it? They will cross-reference your register against your network logs, your procurement records, and sometimes your physical data centre. If they find assets in the environment that aren’t in the register, A.8.1 is a finding.
Ownership. Does every asset have a named owner who is still employed? An asset assigned to a person who left six months ago fails A.8.2. The owner should be the person accountable for the asset — not just whoever originally added the row.
Currency. When was the register last reviewed? If the last update was two years ago, the auditor has reasonable grounds to doubt its accuracy. ISO 27001 does not prescribe a review frequency, but auditors apply common sense: an environment that changes frequently needs a register that keeps pace.
The register doesn’t have to be perfect. Auditors understand operational reality. But it has to be evidently live — updated, reviewed, maintained as an operational process rather than a project artefact.
The Assigned Owner Problem
Ownership is where most hardware asset registers quietly fail.
The asset register says Sarah owns the MacBook Pro with serial number SN-2023-00412. Sarah left the company in February. The MacBook was collected by IT and wiped. It is now assigned to a new hire who joined in March.
The register shows none of this. It shows Sarah, because whoever was responsible for updating the register when Sarah left forgot — or didn’t know it was their job — or knew but didn’t have access to the spreadsheet.
The correct state is: the MacBook is owned by the new hire, or by IT pending reallocation. The correct evidence for the auditor is a history of ownership transfers. What exists instead is stale data and no history at all.
What a Maintained Asset Register Looks Like in Practice
The teams that pass A.8 audits consistently — not by luck, but by design — share a few traits.
Ownership is tied to HR state, not to a name in a spreadsheet. When an employee offboards, any assets assigned to them are surfaced automatically. The offboarding checklist includes hardware recovery as a step with the same urgency as account deactivation.
Location is reviewed on a cadence, not on a guess. Physical location data is either updated by policy at a fixed interval, or is verified against last-seen signals from endpoint management.
New assets enter the register at procurement, not after deployment. The moment a purchase order is approved, the asset gets a record. Serial number, intended assignee, and category are filled in when the device arrives. Not six months later when someone realises it isn’t in the register.
The register is queried, not just read. Teams that maintain good registers use them actively — to answer questions like “how many devices are running Windows 10?” or “which assets are in the London office?” If the register can answer operational questions, it is staying current. If nobody reads it between audits, it isn’t.
The Classification Problem Nobody Talks About
A.8.3 requires rules for the acceptable use of assets and handling procedures. This is often interpreted as a policy document. It is, but it also implies that assets are classified — that you know which assets carry information that warrants elevated handling controls.
A laptop used by a developer with production database access is not the same risk profile as a laptop used by a marketing intern. Your asset register should capture enough information to make this distinction visible.
Most hardware registers don’t. They record the device and its owner. They don’t record the sensitivity of what the device can reach, the criticality of the systems it connects to, or the risk posed by its loss.
This isn’t a checkbox failure for A.8.3 — it’s a missing input for every other part of your security programme. Asset classification is the foundation on which encryption requirements, endpoint management policies, and incident response procedures are built. Without it, you’re making decisions about critical systems without knowing which systems are critical.
Building a Register That Survives Contact with Reality
The asset register isn’t a document you create for auditors. It’s an operational tool that makes your environment legible. When you need to know the blast radius of a ransomware attack, the register tells you which systems are affected. When a vulnerability is published, the register tells you which OS versions are exposed across the fleet. When an employee leaves, the register tells you what to collect.
Built and maintained this way, the register passes audits as a side effect — not as its primary purpose.
The teams that struggle are the ones who build the register for the audit, then let it drift until the next one. The teams that consistently pass are the ones who use the register to run operations, so it stays accurate without special effort.
If your current hardware inventory is a spreadsheet that someone maintains manually, the question isn’t whether it will fail an audit. The question is which audit it will fail.
Start with what you have. Bring it into a system that is designed to be maintained. Assign owners who are tied to live HR records. Add hardware to the register at procurement, not at audit time. Review it on a cadence short enough to matter.
That is what a maintained asset register looks like. That is what Annex A.8 is asking for.