Asset lifecycle

How to build an IT asset inventory you can actually trust

You cannot patch, protect or back up a machine you do not know exists, which is why every security framework puts an IT asset inventory at step one. Yet most inventories are a spreadsheet that was accurate for a fortnight in 2023. This is a walkthrough you can follow at your desk, in order, whether you look after one company's estate, run a managed service provider, or are the entire IT department. At each step, we will name the way it usually goes wrong, because the failure modes are as predictable as the steps.

Step 1: Decide what counts, and pick one system of record

Before you collect anything, write down what "asset" means for you. A workable starting scope for most estates: laptops and desktops, servers and virtual machines, network kit, mobile devices that touch company data, and the software and SaaS subscriptions that run on all of it. You do not have to track everything on day one. You do have to be explicit about what is in and out, or every audit will reopen the argument.

A useful trick is to scope in phases: hardware and operating systems first, because they are discoverable automatically, then installed software, then SaaS and licences, which need invoices and admin consoles rather than scans. Write the phases down too, so "we are not tracking SaaS yet" is a decision rather than an omission.

Then choose exactly one place where the truth lives. It might be your monitoring platform, an ITAM tool, or, at very small scale, a single well-guarded spreadsheet. The tool matters less than the singularity: one system of record, everything else feeds it.

The failure mode: parallel lists. Finance keeps one for depreciation, the service desk keeps another, someone exports a third for an insurance renewal. Within months they disagree, nobody knows which is right, and people quietly stop trusting all of them. An inventory that people do not trust is worse than none, because it answers questions confidently and wrongly.

Step 2: Pull every data source you already have

Do not start by walking around with a clipboard. Most of your inventory already exists, scattered across systems that each see part of the picture. Gather exports from all of them:

• Your monitoring or RMM agent, which knows every device it is installed on, in rich detail.
• Microsoft Entra ID and Intune (or your equivalent directory and MDM), which know every device that has authenticated or enrolled.
• Your antivirus or EDR console, which has its own device list.
• DHCP leases and a network scan, which catch things nothing else sees: printers, switches, the NAS under someone's desk.
• Purchase records and invoices, which know what was bought even if it never came online.

The failure mode: trusting one source and calling it done. Every source has a blind spot. The agent only sees machines it is installed on, which is circular: the devices missing an agent are exactly the ones you most need to find. A network scan misses every remote laptop that never touches the office. The directory holds records for machines that went in a skip two years ago. Only the overlap and the disagreements between sources tell you the truth.

Step 3: Reconcile down to one record per asset

Now merge those exports into your system of record, and be ruthless about identity. The anchor should be the hardware serial number, because it survives everything: renames, reimages, changes of owner, changes of operating system. Hostnames do not. A machine that was rebuilt and renamed will happily appear as two devices forever if the hostname is your key.

Work through the merged list and force every row into one of three buckets: matched across sources and healthy, present in some sources but missing from others, or present in exactly one source. That middle bucket is your immediate work queue. A device the directory knows but the antivirus console does not is not a data quality problem, it is an unprotected endpoint.

The failure mode: deduplicating by deleting. Under time pressure, it is tempting to purge everything that looks stale or doubled-up so the list looks clean. Resist it. A record you cannot explain should be investigated and closed with a reason, not deleted, because "we do not know what this was" is precisely the kind of thing an inventory exists to catch.

Step 4: Give every asset an owner and a lifecycle state

A row that says "Dell Latitude, serial ABC123" is a stocktake, not an inventory. Two more fields turn it into something you can act on. First, an owner: the named person or team the device is assigned to, or the service it exists to run. Second, a lifecycle state, kept brutally simple: on order, in stock, in use, in repair, retired. With those two fields you can answer the questions that actually come up: whose laptop is out of warranty, what do we hand to the new starter on Monday, which servers are due in the next hardware refresh, what did that leaver have.

While you are touching every record anyway, capture purchase date and warranty expiry. They cost seconds per device now and save an afternoon of invoice archaeology later, when you are building a refresh budget or arguing a warranty claim.

The failure mode: the "unknown" that becomes permanent. Some devices will have no obvious owner, and the path of least resistance is to file them under unknown and move on. Six months later a third of the estate is owned by nobody, and the inventory can no longer answer the one question every incident starts with: whose machine is this? Set a rule that unknown is a queue, not a category. Anything unowned for more than thirty days gets investigated or isolated.

Step 5: Wire the inventory into your everyday processes

An inventory built as a project decays from the moment the project ends, because the estate keeps changing and the list does not. The fix is to make your routine processes update it as a side effect, so accuracy stops depending on anyone's memory:

1. Purchasing: a device gets its inventory record when it is ordered, not when someone remembers it exists.
2. Onboarding: assigning kit to a new starter updates the owner field as part of the setup checklist.
3. Offboarding: a leaver's devices are recovered, wiped and re-statused as part of the same runbook that disables their accounts. Our IT offboarding checklist covers why the device you never got back is a breach waiting to happen.
4. Disposal: nothing leaves as e-waste without its record moving to retired, with a wipe certificate attached.

The failure mode: updates that rely on goodwill. If keeping the inventory current is an extra chore performed after the real work, it will be skipped the first busy week and every week after. The update has to live inside the checklist people already follow, or better, happen automatically because an agent reported the change.

Step 6: Audit your IT asset inventory against reality

Finally, put a recurring check in the calendar: quarterly is a sensible default, monthly if you are subject to a compliance framework. The audit is the same move as step 2, repeated: pull fresh exports from the directory, the security tooling and the network, diff them against the system of record, and chase every disagreement to a conclusion. Track one number over time, the count of discrepancies found, and expect it to fall audit by audit.

If you are working towards Cyber Essentials, ISO 27001 or an insurance questionnaire, this cycle is most of the evidence you need: an asset register, a named owner per asset, and proof the register is reviewed. Doing it as a diff between live sources, rather than a fresh manual stocktake, is what makes it repeatable enough to survive contact with a busy quarter.

The failure mode: the audit that always passes. If your review keeps returning zero discrepancies, that is rarely because the estate is perfect. It usually means the audit is checking the inventory against itself, or the person running it has learned that findings create work. Treat a spotless result with the same suspicion you would give a backup job that has never once failed. A good audit finds a handful of surprises; that is evidence it is looking.

Where this fits with Helios

Much of this walkthrough is really an argument for making the inventory a live by-product of tooling rather than a document. That is how Helios approaches it: the same lightweight agent that handles monitoring and patching reports hardware, installed software, warranty and lifecycle state continuously, and the platform cross-references what the agent, Microsoft 365 and your security tooling each see, so the step 3 gaps surface as protection-gap alerts instead of waiting for an audit. Asset records, tickets and device investigations live in one place, which keeps the ownership question from going stale. The walkthrough above works with any toolset, though. The principles, one system of record, reconcile by serial, owner and state on everything, are what matter.