An Asset Inventory You Can Actually Trust

Security wants everything that can be attacked, including the things nobody remembers buying. Finance wants what was paid for, what it is worth now, and what renews. Support wants what is where, who has it, and what it is connected to. One list has to serve all three, and most inventories die because they were built for one of them.

That is why the list built for an audit never survives the audit. It answered one question, once, for one person, and there is no reason for anybody to update it afterwards. The inventory that stays true is the one that at least three different people need to be right in an ordinary week.

So the first job is not technical. Go and ask those three what they would look up and when. Then build one record with enough fields to answer all of it. Anything you cannot name a reader for should not be a field.

Wider than laptops, and this is where most lists are thin. Servers and virtual machines. Phones and tablets. Network switches, the firewall, the wireless access points, the modem the internet provider left in the cupboard. Printers, including the one in the warehouse that prints labels and runs software from a vendor who may or may not still exist.

Then the things with no physical form at all, which are the ones that bite. Domain names and who they are registered to. Certificates and their expiry dates. Software subscriptions, including the ones bought on somebody's card. Licences tied to a specific machine. Cloud accounts. Mailboxes and shared accounts with nobody's name on them. Any system a supplier runs for you that holds your data.

A useful test for whether something belongs on the list. Would you have a problem if it stopped, if it expired, or if a stranger got into it. If yes to any of the three, it goes on, regardless of whether you can pick it up.

The two attributes that matter most across all of it are a renewal date and a support end date. Those are the fields that turn an inventory from a record of the past into something that warns you about next year.

Not because spreadsheets are bad. Because a spreadsheet is updated when somebody remembers, and reality changes when nobody is thinking about the spreadsheet at all.

Three events change what you own, and none of them naturally writes to a file. Somebody joins and is given equipment and accounts. Somebody leaves and hands equipment back, or does not. Something breaks and gets swapped for a spare, usually in a hurry, usually by whoever was nearest.

Notice that the third one is the worst. A swap during an incident is the moment when the record is least likely to be updated and the record is most likely to matter later, because the machine that is now on somebody's desk is not the machine your list says is on somebody's desk. Serial numbers stop matching. Warranty lookups start returning the wrong dates. Everything downstream quietly goes wrong.

The other slow leak is the second copy. Somebody exports the list to answer a question, works on their own version, and now there are two lists that are each partly right. Within months nobody is sure which is current, so people check both and trust neither. One list, in one place, corrected in the original rather than in a copy, is most of what keeps an inventory alive.

The only inventories that stay accurate are the ones nobody has to remember to update. Hook the record to the processes that already happen, so it gets written as a side effect of work people are doing anyway.

Purchasing writes the first entry. When a thing is ordered, it exists, so create the record then with the order number and the expected date. The joiner process assigns it to a person. The repair or swap process updates it, and the ticket should not be closeable until it does. Disposal closes it with a date and a reason.

Automatic discovery then fills in what it can see. Machines checking in, software versions, what is on the network. Treat that as a feed into the record rather than as the record itself, because discovery knows what a thing is and never knows what it is for.

None of this needs an expensive tool. It needs the steps to be part of the job rather than a separate chore, and it needs somebody to notice when a step gets skipped.

Anything that was switched off when the scan ran. Anything on a network segment the scanner cannot reach, which usually includes the interesting part of a factory. Anything without an agent on it, which covers most printers, most cameras, and nearly all specialist equipment.

It will also miss everything that lives entirely in a browser. A subscription somebody bought last spring generates no network traffic worth noticing and appears on no scan. The only reliable trace of it is the payment, which is why the finance card statement is the single best discovery tool most businesses own and the one nobody thinks to use.

And it will miss the ownership question entirely. Discovery can tell you a laptop exists and has been logging in. It cannot tell you whether it belongs to you, to a member of staff personally, or to a contractor who left in March. That answer comes from a person.

A unique identifier, usually the serial number, plus whatever tag you physically stick on it. What it is for, written in business words rather than as a model name. Who has it or who is responsible for it. Where it is. When the warranty ends. When the software on it stops being supported. Who to ring when it breaks, whether that is a supplier or a person.

Two more that are worth the effort and that most lists skip. What it depends on, and what depends on it. If the label printer needs the little server in the corner, write that down on both records. That is the field that turns your inventory into something useful during an incident, and it is the only one that has to be maintained by hand.

Then be ruthless about the rest. If a column has not been read in a year, delete it. Every field somebody has to fill in is a small tax on accuracy, and a form with too many boxes gets filled in badly or skipped altogether. A short record that is true beats a detailed one that is fiction.

Once or twice a year, compare your list against three other lists that already exist. Finance keeps a register of what it paid for. Your identity system knows every account that has logged in recently. The network knows what has been talking on it.

The interesting part is never the agreement. It is the gaps. A machine on the finance register that nobody can find. A device on the network that appears on no list. An account logging in from a laptop you thought was returned. A licence billing every month with nobody assigned to it, and that last one often pays for the whole exercise on its own.

Add a physical walk to that, at least once. Somebody with the list, walking the building, opening cupboards. It takes an afternoon and it always finds things, usually including a machine that has been quietly running an important job for years with nobody's name against it.

The cupboard of old machines is where inventories go to become untrustworthy. Things get removed from service and stay on the record, or leave the building and stay on the record, and after a couple of years the list has enough ghosts in it that people stop believing any of it.

So closing a record needs to be as deliberate as opening one. Date it went, how it was disposed of, who took it, and confirmation that the storage was wiped or destroyed. Where a third party handles disposal, keep whatever they give you as evidence. That paperwork matters far more than it seems to on the day.

Retire the accounts with the device, too. The service account that only that machine used. The licence tied to its serial. The monitoring entry that will otherwise alert somebody at three in the morning about a server that went to the recycler in February.