P.K. SHARMA

Cyber security intelligence, AI governance, practitioner analysis

Build an asset inventory that survives an audit

An auditor is not testing whether you have a spreadsheet. They are testing whether it is true, and whether you can prove what happened to the machines that left.

By Parminder Kumar Sharma · · 9 min read

Rows of dark equipment cases on steel shelving receding into shadow, one pulled forward under cyan light

What an auditor is actually testing

Not whether you have a spreadsheet. Whether the spreadsheet is true.

ISO 27001 A.5.9 asks for an inventory of information and associated assets. A.7.14 asks for secure disposal or re-use of equipment. The gap between those two controls is where most findings live: the period when a machine has left someone's desk and has not yet been dealt with, and nobody can say which state it is in.

The lifecycle the inventory has to survive

  1. KnownAcquired
  2. KnownIn service
  3. UnclearWithdrawn
  4. Evidence neededDisposed
Most inventories are accurate at the first stage and fictional by the fourth.
An illustration of four slabs along a receding track, the first two brightly lit and aligned, the third dim and tilted with a small tag clipped to it, the fourth in shadow with a thin thread running back along the track.
1
2
3
4
  1. 1Four independent sources Directory, endpoint management, purchasing, mobile device management
  2. 2The disagreements An item in one source and not another is the finding
  3. 3The label on the machine State visible to whoever is holding it
  4. 4Disposal evidence Held by you, and linked from the record
The illustration is generated and deliberately wordless; every label on it is real text. The dimming is the argument: most registers are true at the first stage and unverifiable by the fourth.

Why memory produces a worse list than a mediocre export

The instinct on day one is to ask each team what they have. It feels faster and it is the reason most inventories are wrong.

People list what they use. They do not list what is running: the service account created for a migration in 2023, the test environment somebody span up and never turned off, the SaaS tenancy paid on a departmental card. None of those is in anybody's head, and every one of them is in a system that can be exported.

The order matters, so put it the other way round. Export first, from identity, endpoint management, the cloud console and the finance system. Then take that list to the teams and ask what it is missing and what should not be there. People are far better at correcting a list than at producing one, and the corrections are themselves evidence that somebody reviewed it.

Days 1 to 3: build the first version from systems, not from memory

1

Pull from everything that already knows

Your directory, your endpoint management tool, your DHCP leases, your purchase records, your mobile device management, your SaaS admin consoles. Each holds a partial truth and none holds all of it.

Do not start by walking around with a clipboard. Start by joining what your systems already assert, then walk around to resolve the disagreements.

You should see: Four or more independent sources, exported to one place.

2

Reconcile and keep the disagreements

The discrepancies are the finding. A device in endpoint management but not in purchasing was probably bought outside process. A device in purchasing but not in endpoint management is unmanaged and may be unpatched. Both are worth more than a clean list.

You should see: A list of items that appear in one source and not another.

3

Decide what an asset is, and write it down

Does a personal phone with mail on it count? A virtual machine that lives for six hours? A SaaS tenancy? There is no universally correct answer, and an auditor will accept a reasoned rule applied consistently far more readily than an unstated one applied inconsistently.

You should see: A one-line scope rule you can apply consistently to an edge case.

Days 4 to 6: add what the standard actually wants

An asset register that lists serial numbers and nothing else answers the inventory question and none of the ones that follow it.

What most registers hold

  • Make, model, serial number.
  • Purchase date and cost.
  • Assigned user, often stale.
  • Location, often the office it was first delivered to.

What makes it defensible

  • An owner who knows they own it, not just a name in a column.
  • What class of information it holds or can reach.
  • Its current lifecycle state, including withdrawn and awaiting disposal.
  • The disposal evidence when it leaves, linked to the record.

The second column is what turns an inventory from a purchasing artefact into a security control.

4

Attach an information classification to each asset

This is what A.5.9 means by "information and associated assets". The asset matters because of what it holds. A laptop with nothing on it and a laptop holding a client case file are the same hardware and completely different risks.

You should see: You can filter the register to everything holding client-confidential data.

5

Add lifecycle state, and make it visible on the asset

In service, in store, awaiting repair, awaiting disposal, data wiped, disposed. The state has to travel with the hardware, because the machine will be handled by people who cannot reach your systems: a courier, a recycler, whoever buys it at auction.

You should see: Somebody holding a device can tell its state without opening a system.

The four columns that decide whether it survives

Most inventories fail an audit on the same four fields, and none of them is the one people spend their time on.

What an assessor checks, and what a failing inventory usually holds

FieldWhat makes it passWhat fails
OwnerA named person who knows they own it and can say what it doesA team name, or a person who left
ClassificationApplied consistently, with a rule anybody could reapply to a new assetApplied by whoever created the row, differently each time
LocationSpecific enough to find the thing, including which cloud tenancy or regionOn-premises, or Cloud
DisposalA record showing the asset left, when, and what happened to the data on itThe row is deleted, so nothing shows it ever existed
Drawn from the questions actually asked in a stage 2 audit rather than from the standard's wording. The left column is the field; the right is the answer that ends the conversation early.

The disposal column is the one that turns a good inventory into a failing one. A deleted row is not evidence of disposal; it is the absence of evidence about an asset that definitely existed. An auditor who samples last year's purchase records and cannot trace three of them to either a live row or a disposal record has found a gap in the system rather than in the spreadsheet.

Days 7 to 10: close the disposal gap

This is the part that fails audits.

6

Define what happens between desk and disposal

Most organisations have a cupboard. A cupboard is fine; an undocumented cupboard is not. Write down where withdrawn kit goes, who controls access to it, and how long things may sit there.

You should see: A named place withdrawn equipment goes, and a named person responsible for it.

7

Choose the sanitisation method deliberately

Clear, purge or destroy, decided by the sensitivity of what was held and whether the media leaves your control. Guessing here is how organisations end up shredding drives they could have resold and reselling drives they should have destroyed.

You should see: A written reason for the method, per media type, that an assessor would accept.

8

Keep the certificate, and link it to the record

A certificate in a supplier's portal that nobody in your organisation can produce is not evidence. Store it, and link it from the asset record so the chain runs from acquisition to destruction without a gap.

You should see: From any disposed asset, you can reach the evidence of how it was sanitised.

Where it goes wrong after month two

The inventory is not the deliverable. A process that keeps it true is, and three things reliably kill it.

It is nobody's job. An inventory maintained by whoever remembers is an inventory that decays at the rate people forget. Name an owner for the inventory itself, separately from the owners of the assets in it.

It is updated by hand from systems that could update it. Every field you retype is a field that will drift. If identity, endpoint management and the cloud console can export, the reconciliation should be scheduled rather than remembered, and the exception list is what a person actually reviews.

Joiners and leavers are treated as an HR process. Most asset drift enters through people arriving and leaving. If the leaver process does not produce a record of what came back, the disposal column starts failing again about six weeks after the audit.

The test that predicts the next audit is simple. Pick three assets bought eighteen months ago from the finance records, at random, and trace each one to a live row or a disposal record. If you cannot do all three, the process is already broken and the spreadsheet is only reporting it late.

Run that trace yourself, on a date you choose, rather than waiting for an assessor to run it on a date they choose. The finding is identical either way; only the cost of it differs, because one version leaves you six months to fix the process and the other leaves you a nonconformity to close under a clock.

Keeping it true

Take this with you

What makes an inventory survive an audit

  • It is reconciled against at least two independent systems on a defined schedule, and the reconciliation is dated.
  • Every asset has an owner who has confirmed they own it, not a name inherited from a purchase order.
  • Information classification is recorded, so the register answers what is at risk rather than what was bought.
  • Lifecycle state is recorded and is visible on the asset itself.
  • Withdrawn equipment has a defined location, a responsible person and a time limit.
  • Disposal evidence is stored by you and linked from the asset record.
  • The scope rule for what counts as an asset is written down.
  • The last review is dated and somebody can say what it found.

Verified

Control references are to ISO/IEC 27001:2022 Annex A. Written 5 August 2026. Control numbers and titles are identifiers; no standard text is reproduced.

Share this tutorial

Free to share with your team or your network.

Related briefings

The briefing, in your inbox

Practitioner analysis of cyber and AI security news. No vendor noise.

One email per briefing. Unsubscribe any time.