An information security management system is only as honest as its asset inventory. Almost everything a certification auditor will ask you to demonstrate — that access is restricted to the right people, that endpoints are hardened, that media is disposed of securely, that leavers return their kit — assumes you can produce a complete, current list of what you are protecting and who is accountable for it. ISO/IEC 27001:2022 makes that assumption explicit in Annex A control 5.9, and it is one of the first things tested and one of the most common places certification stumbles. This guide explains what the control requires, how auditors sample it, how classification, ownership and risk connect to it, where it overlaps with Cyber Essentials and UK GDPR, and how to build an inventory that survives the audit rather than one that merely exists in a folder.
One point up front, because it matters: CPCON is not a certification body and does not certify organisations to ISO 27001. The certificate decision belongs to your UKAS-accredited certification body. What CPCON delivers is the underlying inventory evidence the standard asks you to produce — counted and reconciled by an independent team — so that when the auditor starts sampling, the answers are already on the floor.
What control A 5.9 actually says
ISO/IEC 27001:2022 Annex A control 5.9 — Inventory of information and other associated assets — is short and unforgiving: an inventory of information and other associated assets, including owners, shall be developed and maintained. It sits in the organisational theme of the 2022 control set and merges what the 2013 edition treated as two controls: the inventory itself (old A.8.1.1) and ownership (old A.8.1.2). Since the transition deadline for the 2013 edition passed in October 2025, every certification audit now runs against this wording.
Three words carry the weight. Inventory: a structured record, not tribal knowledge spread across spreadsheets, mailboxes and the service desk. Owners: a named person or role accountable for each asset or group of assets — because controls without owners do not get operated. Maintained: the inventory reflects joiners, leavers, moves and disposals as they happen, not as they are remembered the week before the audit.
The detail behind the headline lives in ISO/IEC 27002:2022, the companion code of practice. It is guidance rather than a checklist — the standard deliberately avoids prescribing fields — but it sets clear expectations: the inventory should be accurate, up to date, consistent with other inventories, and aligned to information classification; each asset should have a designated owner; and the owner should be accountable for the asset across its lifecycle, from inventorying and classification through to correct handling on transfer and disposal. Auditors read 27002 as the benchmark for what "good" looks like, even though they certify against 27001.
The logic is older than the standard: you cannot classify, protect, patch or return what you have not identified. Almost every other Annex A control presupposes 5.9 — which is why an inventory finding tends to cascade into findings elsewhere.
“Information and other associated assets” — the scope
The control deliberately reaches beyond hardware. The accompanying guidance in ISO/IEC 27002:2022 expects organisations to decide the right granularity, but a defensible inventory usually covers:
| Asset type | Examples | Typical owner |
|---|---|---|
| Information | Databases, files, records, contracts, intellectual property, backups, archived media | Data / process owner |
| Hardware | Laptops, desktops, mobiles, servers, network kit, removable media, IoT/OT devices | IT / named custodian |
| Software | Applications, operating systems, firmware, licences, development tooling | Application owner |
| Cloud & services | SaaS subscriptions, IaaS/PaaS tenants, hosting, comms links, outsourced processing | Service owner |
| Physical & supporting | Comms rooms, access-controlled areas, cabling, power, HVAC, fire suppression | Facilities / site owner |
| People & knowledge | Key roles, qualifications, undocumented know-how, supplier dependencies | Line management / HR |
The art is in the granularity. List every cable and you produce an inventory nobody maintains; list "all IT" as a single line and you have no inventory at all. The standard expects a sensible level: individual devices and information assets where they carry distinct risk, ownership or handling requirements, and groups where they do not. A practical rule is to itemise anything that can be lost, stolen, moved or independently disposed of — which is exactly the population a physical count addresses — and to group truly homogeneous, fixed infrastructure.
Two scoping mistakes recur. The first is treating the inventory as an IT-only artefact and forgetting non-digital information assets: paper records still in scope, archived media, and the know-how concentrated in a handful of people. The second is letting the inventory scope drift away from the ISMS scope defined for certification — assets inside the certified boundary that never make the list, or assets on the list that sit outside scope without explanation. Auditors check both edges.
In practice, the hardware layer is where inventories fail first — devices are numerous, mobile and easy to lose track of — and it is the layer your auditor can physically test. That is why the device inventory deserves the most operational discipline, and why a wall-to-wall IT asset inventory is the most reliable foundation for the whole control.
What an A 5.9 inventory record should contain
The standard does not mandate a field list, but auditors and ISO/IEC 27002 converge on the same practical minimum. An inventory line that cannot answer "what is it, who owns it, where is it, how sensitive is it, and when did we last confirm it exists?" is hard to defend. A workable record set:
| Field | Why the auditor cares |
|---|---|
| Asset identifier | Unique tag/ID — the anchor the auditor scans during two-way sampling. |
| Asset type & description | Class and enough detail to recognise the asset on the floor (make, model, serial). |
| Owner | Named person or role accountable for the asset, reconciled to HR — mandatory under A 5.9. |
| Custodian / user | Who currently holds or operates the asset, where this differs from the owner. |
| Location | Site, building and room — granular enough for record-to-floor sampling. |
| Classification | Confidentiality / integrity / availability rating that drives the protection level. |
| Status | In use, in store, in transit, awaiting disposal — and the data-bearing flag. |
| Last verified | Date and method of the most recent physical confirmation — the proof of maintenance. |
The last-verified field is the one most inventories omit and the one that most clearly separates a maintained inventory from a populated database. A line that asserts an asset exists but carries no evidence of when that was last confirmed is, to an auditor, an assertion rather than a control. Stamping the date and method of physical verification against every line is what makes "maintained" demonstrable.
Ownership: the word auditors test hardest
"Including owners" is three words in the control and a recurring source of nonconformities in practice. ISO/IEC 27002:2022 is explicit that the asset owner is accountable across the lifecycle: ensuring assets are inventoried and classified, defining and periodically reviewing access restrictions and classifications, and ensuring proper handling when the asset is deleted, destroyed, transferred or returned. Ownership is accountability, not custody — the owner need not be the daily user.
Common failures the auditor will surface: blank owner fields; "IT" or "Facilities" used as a catch-all owner for thousands of assets; owners who have left the organisation; and owners who, when asked, do not know they own the asset or what that entails. The fix is to treat owner as mandatory data, reconciled to current HR records, assigned to named individuals or clearly defined roles, and backed by an acceptable-use and handling expectation the owner has actually seen. Where assets are grouped, the group needs a single accountable owner, not a committee.
Classification: linking the inventory to protection
A 5.9 produces the list; A 5.12 (classification of information) decides how hard each item must be protected. The inventory is where the two meet, because classification is recorded against assets and then drives the controls applied to them. Most UK organisations operate a simple tiered scheme — a four-level model is common and maps cleanly onto government-style handling — assessed primarily on confidentiality, with integrity and availability considered where they matter:
| Level | Impact of disclosure | Typical examples |
|---|---|---|
| Public | Disclosure causes no harm; published or intended for release | Marketing material, published reports |
| Internal | For internal use; limited harm if disclosed | Internal procedures, org charts, most email |
| Confidential | Disclosure causes real business or regulatory harm | Customer PII, contracts, financials, source code |
| Strictly confidential | Disclosure causes severe harm; tightly need-to-know | Credentials, encryption keys, M&A, special-category data |
The classification on an asset is not decoration: it should change how the asset is handled, stored, transmitted and disposed of, and it feeds the risk assessment. A device or repository holding special-category personal data under UK GDPR should carry a classification that pulls in stronger controls than one holding published material. Auditors test the chain — pick a confidential asset from the inventory and ask to see the controls its classification implies — so an inventory whose classifications are blank, default or inconsistent fails on more than one control at once.
How the inventory feeds the risk assessment
ISO 27001 clause 6.1.2 gives you freedom over your risk assessment method, and the 2022 standard does not force an asset-based approach. But in practice the inventory still anchors the risk work in two ways. First, even a scenario-based or threat-based assessment has to know what is in scope to be protected — and the inventory is that boundary. Second, the controls you choose and document in the Statement of Applicability are applied to assets and asset groups, so the inventory is the population over which "are the controls actually operating?" is answered.
The dependency runs in one direction and it is unforgiving: if the inventory is incomplete, the risk assessment beneath it has blind spots it does not know about, and the Statement of Applicability asserts coverage it cannot demonstrate. An asset that was never inventoried was never risk-assessed and is protected by accident if at all. This is precisely why auditors trace between the inventory, the risk assessment and the Statement of Applicability — and why the completeness of the inventory is load-bearing for the whole ISMS, not just for control 5.9 in isolation.
How auditors test it
Certification runs in stages — a Stage 1 documentation review, a Stage 2 implementation audit, then annual surveillance and three-yearly recertification — and the asset inventory is tested at every one of them, because it is cheap to sample and revealing when it fails. Expect:
- Two-way sampling. Floor-to-record: the auditor points at a laptop, a switch, a server and asks you to find it in the inventory with the correct owner and location. Record-to-floor: the auditor picks lines from the inventory and asks to see the asset. Either direction failing suggests the inventory is not complete or not maintained.
- Lifecycle probes. Recent joiners, leavers, refreshes and disposals, traced into the inventory. A leaver whose laptop is still “assigned” three months on is a finding against A 5.9 and the return-of-assets control (A 5.11) in one move.
- Maintenance evidence. Last-verified dates, reconciliation reports, cycle-count records. An inventory with no evidence of upkeep is treated as a snapshot, not a control.
- Ownership challenge. The auditor may go to a named owner and ask whether they know they own the asset and what that means. Owners who are surprised, or who have left, turn a tidy spreadsheet into a finding.
- Consistency checks. The inventory against the Statement of Applicability scope, the risk assessment, the classification scheme, MDM enrolment and the fixed asset register. Large unexplained gaps between systems invite deeper digging.
Connected controls multiply the exposure. The inventory is the backbone several other Annex A controls hang off, and a weak inventory pulls them down with it:
| Control | Title | Dependence on the inventory |
|---|---|---|
| A 5.9 | Inventory of information and other associated assets | The inventory itself, including owners |
| A 5.10 | Acceptable use of information and associated assets | Rules per asset class — needs the asset list |
| A 5.11 | Return of assets | Recovery on termination — leaver kit traced through the inventory |
| A 5.12 | Classification of information | The classification scheme applied to inventoried assets |
| A 7.9 | Security of assets off-premises | Home and field devices — the part that drifts fastest |
| A 7.10 | Storage media | Removable and archive media tracked through disposal |
| A 7.14 | Secure disposal or re-use of equipment | Data destruction evidence against disposed assets |
| A 8.1 | User endpoint devices | Endpoint hardening applied to a known device population |
Get 5.9 wrong and the nonconformities rarely come alone: a single unreturned leaver laptop can be written up against A 5.9 (inventory not maintained), A 5.11 (return of assets) and A 7.9 (assets off-premises) simultaneously, and if it held personal data it becomes a UK GDPR exposure on top.
The Statement of Applicability and the scope boundary
The Statement of Applicability (SoA) is the document that lists every Annex A control, states whether it applies, and justifies any exclusion. A 5.9 is one of the controls hardest to exclude credibly — because so many others depend on it — so in practice it is marked applicable, and the SoA then becomes one of the documents the auditor reads the inventory against. Two consistency tests follow directly.
First, the inventory has to cover the certified scope. The ISMS scope statement defines a boundary — sites, business units, services — and every asset inside that boundary should appear in the inventory. Assets in scope that are missing from the list are a completeness failure; assets on the list that sit outside scope need an explanation, because an inventory that quietly mixes in-scope and out-of-scope assets makes it impossible to tell whether the controls actually cover what they claim to. Second, where the inventory and the SoA disagree about an asset class — the SoA implies a control over a category of devices the inventory does not record — the auditor has found a thread to pull. Keeping the inventory scope and the ISMS scope deliberately aligned, and being able to explain any difference, is what stops these checks turning into findings.
The nonconformities that recur
Across certification and surveillance audits, inventory findings cluster into a small set of recurring patterns. Knowing them is the cheapest way to avoid them:
- Blank or generic owners. Owner fields left empty, or "IT" used as a blanket owner for the whole estate, against a control that explicitly says "including owners". The fix is owner as mandatory data, named to individuals or defined roles.
- Stale or absent verification dates. An inventory with no evidence of when assets were last confirmed reads as a snapshot, not a maintained control. Last-verified dates and reconciliation reports are the proof of maintenance.
- Floor-to-record gaps. The auditor points at a device that is not in the inventory — usually stored, recently arrived, or shadow IT — exposing that the list is not complete.
- Record-to-floor ghosts. Inventory lines the organisation cannot physically produce, because the asset was moved, swapped or disposed of without the record catching up.
- Unreturned leaver assets. Kit still assigned to people who have left — a single finding that can be written against the inventory, return-of-assets and off-premises controls at once.
- Classification missing or default. Assets with no confidentiality rating, or everything defaulted to one level, so the classification cannot be driving the protection it is supposed to.
- Inventory inconsistent with other records. Large unexplained gaps between the inventory and MDM, the CMDB or the fixed asset register, inviting the auditor to question which — if any — is right.
Almost every item on that list is a symptom of the same root cause: an inventory that was populated once and never physically re-grounded in reality. Each is closed by the same discipline — an independent count, owners as data, classification applied, and a dated reconciliation — which is why a single verification project tends to clear several potential findings together.
Physical evidence: why discovery is not enough
The most common objection in a Stage 2 audit is "our MDM and discovery tools give us a live inventory." They are valuable, and they are structurally incomplete. Agent-based discovery, MDM and RMM tooling enumerate devices that are powered, connected and enrolled at scan time. By construction they cannot see the spare laptops in a cupboard, the switch awaiting disposal, the unreturned leaver device sitting offline at home, equipment on isolated or OT networks, or any non-digital information asset at all. Worse, absence from a scan is ambiguous — a missing device might be off, in transit, re-imaged under a new name, or genuinely gone — so discovery cannot reliably prove a disposal happened either.
This is exactly why physical sampling is a standard part of the audit, and why a periodic physical verification is the evidence that an inventory is complete rather than merely populated. Our companion guide on why CMDBs lie without a physical audit sets out, source by source, what each automated tool systematically misses — the same blind spots an auditor exploits when they walk to the comms room and start pointing at kit.
The Cyber Essentials overlap
UK organisations rarely face ISO 27001 alone — Cyber Essentials is the other assessment that stands or falls on the device inventory. The self-assessment requires you to define scope and declare the devices within it, including make and operating system, and an unsupported operating system inside scope is an automatic fail. Cyber Essentials Plus adds an independent technical test of a sample of those devices. The NCSC’s own guidance treats asset management not as a standalone control but as the foundation that makes the five technical controls possible.
The overlap is not incidental: both schemes are asking the same underlying question in different language. ISO 27001 wants "an inventory of information and other associated assets, including owners"; Cyber Essentials wants "the devices in scope, with make and operating system." A laptop you cannot find for the auditor is the same laptop you cannot honestly declare on the Cyber Essentials self-assessment. An end-of-life operating system you did not know was still in use is a finding in one and a fail in the other.
The practical conclusion: build one device inventory, physically verified, with owners, operating systems and status — and let it feed the ISO 27001 evidence pack, the Cyber Essentials declaration, UK GDPR Article 30 records and the fixed asset register simultaneously. Maintaining four contradictory lists is how organisations fail all four.
UK GDPR: the same inventory does double duty
The asset inventory is also the practical foundation for data protection. UK GDPR Article 30 requires records of processing activities, and those records assume you know which systems and devices hold personal data — a mapping that an asset inventory, classified for confidentiality and flagged for personal data, makes possible rather than guesswork. The same is true of breach response: the Article 33 obligation to assess and, where required, notify a breach within 72 hours is impractical for a lost laptop you did not know existed or could not confirm what it held.
Secure disposal closes the loop. Annex A 7.14 (secure disposal or re-use of equipment) and the UK GDPR storage-limitation and integrity-and-confidentiality principles both expect data-bearing assets to be disposed of with evidence. An inventory that flags every data-bearing device and reconciles disposals against data-destruction certificates turns a recurring audit finding — kit gone with no destruction record — into a controlled, evidenced process.
Building an inventory that survives sampling
- Start physical. A wall-to-wall IT asset inventory establishes what actually exists — including the stored, offline and unreturned devices no discovery tool can see — and the same field discipline extends to full fixed asset verification where the estate is wider than IT.
- Tag everything. Durable asset tags give every device a scannable identity, so two-way sampling takes seconds instead of arguments.
- Assign owners as data, not intention. Owner is a mandatory field, reconciled to HR records — A 5.9 says “including owners”, and auditors check the named owner actually knows they own it.
- Classify against the scheme. Record a confidentiality (and, where it matters, integrity and availability) rating on every asset, and make sure the rating actually drives the handling and disposal controls applied to it.
- Reconcile the sources. Physical count against discovery/MDM against CMDB against register, on a defined cycle — our guide on why CMDBs lie without a physical audit explains what each source systematically misses.
- Wire in the lifecycle. Joiner, leaver, move and disposal processes update the inventory at the moment they happen, with data-destruction certificates filed against disposed data-bearing assets and a last-verified date stamped on every confirmed line.
“Maintained”: surviving surveillance, not just certification
Certification is not the finish line. After the initial Stage 2 audit, the certificate is sustained through annual surveillance audits and a full recertification at the three-year point — and the asset inventory is sampled at every one of them. The word that does the work across that cycle is maintained. An inventory that looked complete in the certification audit but has received no upkeep since will, at the first surveillance visit, show the symptoms the auditor looks for: new joiners with kit that is not recorded, leavers whose devices are still assigned, disposals with no trail, and last-verified dates that have not moved.
Treating the baseline count as the end of the work is therefore the most common way organisations pass certification and then collect findings at surveillance. The inventory has to be wired into the events that change it. Joiner, mover, leaver and disposal processes should update the inventory at the moment of the event, not in a pre-audit scramble. High-churn classes — laptops, mobiles, loan kit — warrant rolling cycle counts so the record stays close to reality without a full re-count. A standing physical-to-CMDB-to-register reconciliation, owned and dated, keeps the three systems converged. And a last-verified date stamped on every confirmed line is the single most persuasive piece of evidence that the inventory is a living control rather than an annual artefact.
Done this way, the surveillance audit becomes a confirmation rather than a risk: the auditor samples, the samples reconcile, the dates are recent, and the findings stay closed. That is the practical meaning of "developed and maintained" — and it is the difference between a certificate you defend with evidence and one you re-earn under pressure every year.
Sector context: regulated environments
For sectors where supervisory expectations sit on top of certification, the inventory carries more weight still. In financial services, operational resilience and outsourcing rules push firms to evidence control over the technology underpinning important business services — which is impossible without knowing what that technology is and where it sits. Our financial services page sets out how asset verification supports that picture. The same logic applies anywhere a regulator, insurer or large customer can ask you to prove, not assert, what you hold.
An A 5.9 readiness checklist
Before a certification or surveillance audit, a quick self-test against the questions auditors actually ask will tell you where the inventory is exposed:
- Can you produce a single, structured inventory of information and associated assets in scope — not several disagreeing spreadsheets?
- Does every line carry a named owner reconciled to current HR records, and would that owner confirm they own it?
- Does every asset carry a confidentiality classification that actually drives how it is handled, stored and disposed of?
- Can you take any device on the floor and find it in the inventory, and any inventory line and produce the device?
- Does every confirmed line carry a recent last-verified date and a method, evidencing that the inventory is maintained?
- Are recent joiners, leavers, moves and disposals reflected — with data-destruction certificates filed against disposed data-bearing assets?
- Does the inventory scope match the ISMS scope and reconcile to the CMDB, MDM and the fixed asset register without large unexplained gaps?
A "no" or "not sure" against any of these is precisely where an auditor’s sampling tends to land — and exactly what an independent physical verification is designed to close.
Where CPCON fits
CPCON is not a certification body and does not issue audit opinions — the certificate decision belongs to your UKAS-accredited auditor, and our independence from that process is the point. What we bring is 30 years and 4,500+ projects of physical verification discipline: independent counts, asset tagging, owner assignment reconciled to HR, and serial-level reconciliation to your CMDB, ITAM tool and fixed asset register. The deliverable is an A 5.9 inventory that has been counted rather than asserted — defensible evidence behind your control before the auditor starts sampling, and a foundation that simultaneously serves Cyber Essentials, UK GDPR Article 30 and the fixed asset register. To turn the baseline into a maintained inventory, the same teams set up cycle counting on high-churn classes and RFID tracking where volumes justify reading a room in minutes.