IT Asset Management: What to Track and Why

Most IT asset tracking starts as a spreadsheet, gets out of date within six months, and ends up being less useful than just walking around and looking at things.

The problem isn't the spreadsheet. The problem is tracking assets without a clear reason for tracking them. If you don't know why you're recording a piece of information, you won't bother keeping it current.

Here's what actually matters and why.

What an asset inventory is for

An asset inventory serves three distinct purposes, and which one you're optimizing for changes what you track.

Operational support. When something breaks, you need to know what you have, where it is, and how to get into it. This is the day-to-day value.

License compliance. For software, you need to know what you're running, how many seats you have, and when renewals are due. Audit risk is real, and "we think we have enough licenses" is not a defense.

Budget planning. Hardware has a lifespan. A good asset inventory tells you what's approaching end of life before you find out the hard way.

These purposes are related but not identical. The level of detail that helps with compliance audits is different from what helps with budget planning.

Hardware: what to track

For every physical device that matters, you want:

• Asset tag or serial number
• Make, model, and specs (for servers and workstations, at minimum: CPU, RAM, storage)
• Location (site, rack, or desk)
• Assigned user or function
• Purchase date and warranty expiry
• Current status: in service, spare, decommissioned

The "current status" field is the one that decays fastest and matters most. A decommissioned server that's still in your inventory as active is noise. Noise erodes trust in the whole system.

For network equipment, also track: firmware version, management IP, and what it's connected to. This is the information you want at 2am when something's down, not the information you want to spend 20 minutes finding.

Software: what to track

Software asset management is harder than hardware because software changes faster and the compliance stakes are higher.

For each software title in use:

• Product name and version
• Vendor and license type (per seat, per device, subscription, perpetual)
• Number of licenses owned
• Number of licenses in use (if you can get this automatically, do it)
• Renewal date and cost
• Who manages the account

The gap between licenses owned and licenses in use is where audit risk lives. You either have too many (wasted spend) or too few (compliance violation). Neither is good and both are common.

What most inventories miss

Virtual machines. VMs are easy to spin up and easy to forget. A VM that nobody's actively using is still running, still consuming resources, and still a potential security exposure. Include them.

Cloud resources. If you're running anything in AWS, Azure, or GCP, those resources need to be tracked alongside physical assets. A cloud VM is still an asset. An untagged cloud resource with no owner is a liability.

End-of-life dates. Operating system support lifecycles matter. A server running Windows Server 2012 isn't just old, it's a known security problem. Your inventory should surface this without you having to manually calculate it.

The "why" field. For anything non-standard, a notes field that explains why it exists. The server that's still running a legacy app. The workstation with the old OS because the specialist software won't run on anything newer. Without that context, someone will eventually "fix" it.

Keeping it current

The only system that works is updating the inventory as part of the work, not as a separate task.

New device deployed: add it before you close the ticket. Device retired: mark it decommissioned the same day. Software license renewed: update the renewal date immediately.

This sounds like overhead. It's about two minutes per asset event. The alternative is a quarterly "let's update the asset inventory" project that never quite happens.

Some environments can pull asset data automatically through RMM tools or configuration management databases. If you have that capability, use it, but treat it as a supplement rather than a replacement. Automated discovery finds what's running. It doesn't know what it's for, who owns it, or when the warranty expires.

The minimum viable asset inventory

If you're starting from nothing:

1. Every server, physical and virtual, with hostname, IP, role, and OS
2. Every network device with location and management IP
3. Every software title with license count and renewal date
4. Purchase date and warranty expiry for anything that's cost-significant to replace

That's enough to handle most operational situations and most compliance questions. Everything else builds on top of it.

The goal isn't a perfect database. It's a system current enough to trust when you need it.