IT asset management best practices are the habits that let you prove what you own, what you run, and what you are entitled to run at any moment, especially the moment a publisher sends an audit letter. Most best-practice lists optimize for a tidy internal inventory. This one optimizes for something harder, surviving a Microsoft, Oracle, or IBM audit with your budget intact and cutting the software cost you are carrying for no reason. If you want the foundational definition of the discipline, start with our cornerstone on IT asset management. What follows assumes you already know what ITAM is and focuses on the practices that actually hold up when money is on the line.
What separates audit-ready ITAM from internally tidy ITAM?
Audit-ready ITAM is built around your entitlement position, while tidy ITAM is built around your inventory. That difference sounds small and it is the whole game.
Most ITAM guidance is written by the companies selling ITAM tools, and a tool is very good at telling you what is installed. What is installed is only half of an audit. A publisher does not care how neat your asset register looks. They compare what you have deployed against what you have bought, and they invoice you for the difference. If your program is organized to answer “what do we have running,” you will lose the argument that matters, which is “what are we allowed to run.”
I spent years on the other side of that table, running the audits that produced those invoices. The organizations that came through them well were never the ones with the prettiest inventory. They were the ones who could produce their license position on demand and defend it line by line.
How do you keep one authoritative record of your estate?
Pick one system as the single source of truth and make every other feed reconcile into it, rather than letting three or four tools each hold a partial and slightly different version of reality.
The failure mode here is common. Procurement has a spreadsheet, the endpoint tool has a discovery database, finance has the purchase records, and the cloud consoles have their own billing views. None of them fully agree, and when an audit lands, the organization spends the first three weeks just working out which number to trust. Those three weeks are exactly when you should be building your defense, not arguing internally about your own data.
One authoritative record does not mean one tool does everything. It means one record is designated as the version you will defend, and everything else is treated as input that has to be reconciled against it. That record should carry not just the asset, but the entitlement tied to it, so that the answer to “are we compliant on this product” lives in one place.
Why reconcile entitlements against deployments, not just installs?
Because the audit is a reconciliation, so your defense has to be one too. Tracking installs tells you what is running. Reconciling entitlements against deployments tells you whether you are allowed to run it, which is the only question a publisher is actually asking.
The international standard makes this split explicit. The ISO/IEC 19770 family devotes one part, 19770-2, to software identification tags that describe what is installed, and a separate part, 19770-3, to a schema for software entitlements, what you are licensed to use. The standard treats those as two different data problems for a reason. Your compliance position is the gap between them, and you cannot see the gap if you only measure one side.
This is where deployments matter more than installs. A product can be installed and unused, installed under the wrong metric, or running in a virtualized environment that changes how it is counted entirely. IBM sub-capacity licensing, Oracle’s processor rules, and Microsoft’s per-user and per-core models all turn “it is installed” into a far more complicated question. Reconciling against your actual entitlements, including the product use rights and amendments buried in your contracts, is what turns a raw install count into a defensible number. Our software license audit defense guide goes deeper on how those reconciliations play out under a live audit.
What does covering the whole estate mean for cloud and SaaS?
It means your ITAM program has to include cloud subscriptions, SaaS seats, and hybrid deployments, not just the servers and desktops you can physically point at. Cloud and SaaS are where both the waste and the audit exposure now concentrate.
On-premise licensing is a known quantity for most organizations. The blind spots are elsewhere. SaaS seats get provisioned and never reclaimed, so you keep paying for people who left or never logged in. Cloud services get spun up for a project and keep billing long after the project ends. And hybrid arrangements, where an on-premise license is stretched to cover cloud use, are a frequent source of audit findings because the rights that govern them are easy to misread.
A cost lens and an audit lens point at the same place here. The unused Microsoft 365 seats you are paying for are also the cleanest optimization win in most estates, often in the range of 20 to 40 percent of the affected spend once you reconcile assigned licenses against active users. Covering the whole estate is not a compliance nicety. It is where the money is.
How should your ITAM calendar map to renewal and audit dates?
Your ITAM review calendar should be anchored to your renewal windows and your known audit exposure, not to an arbitrary annual cycle. The work has to be done before the event, not in response to it.
The lifecycle most tool vendors describe runs through planning, acquisition, utilization, maintenance, and renewal or disposal. That model is fine, but it is neutral about timing, and timing is everything in this business. A renewal negotiated cold, in the last weeks before it expires, is a renewal negotiated from weakness. The same is true of an audit response that starts the day the letter arrives.
The practical rule is to work backward from the dates that carry commercial weight. Enterprise Agreement renewals, Oracle and IBM renewal windows, and any true-up dates should each trigger a full reconciliation 90 to 120 days ahead. That lead time is what lets you correct your deployment position, retire what you do not need, and walk into the conversation knowing your numbers cold. If your program only wakes up when a vendor contacts you, you have already conceded the initiative.
Why is the entitlement position, not the asset list, the defensible artifact?
Because when a publisher challenges you, they attack your entitlements, and a list of assets does not answer that challenge. Your entitlement position, the documented proof of what you are licensed to run, is the artifact that actually settles the argument.
An asset list says “here is what we have.” An entitlement position says “here is what we are contractually allowed to have, and here is the paperwork that proves it.” Only the second one survives contact with an auditor. When you cannot produce your entitlements, the publisher’s reconstruction of your position becomes the default, and their reconstruction is rarely generous.
Building that artifact means keeping your contracts, amendments, order histories, true-up records, and product use rights organized and mapped to deployments, not filed away in a legal archive nobody has opened in years. Treat the entitlement position as a living document you can produce in 48 hours, because that is roughly the window you will have when it matters. For the software-specific view of this, our explainer on what software asset management is covers how the license layer sits inside the wider estate.
Who should own the reconciliation between the tool team and the contract holders?
One named owner has to be accountable for the reconciliation itself, sitting between the team that runs the discovery tools and whoever holds the contracts, because that gap is where most programs quietly fail.
Here is the pattern I see constantly. The IT team owns the tools and knows what is deployed. Procurement or legal owns the contracts and knows what was bought. Neither owns the reconciliation between the two, so it does not get done until an audit forces it. Everyone is doing their job and the organization is still exposed, because the job that protects you is the one nobody was assigned.
Fix this by naming a single accountable owner for the license position, with a standing mandate to pull data from both sides and keep the reconciliation current. In a large organization that is a SAM function. In a mid-size one it may be a single person, or a service you bring in. What matters is that the reconciliation has an owner, not that the owner is internal. If you are weighing whether to build that capability or buy it, our note on when to outsource IT asset management walks through the trade-off.
Where UMS fits
We used to run these audits for the publishers. That is not a tagline, it is where our team learned exactly how a Microsoft, Oracle, or IBM claim gets built, which deployment details get weaponized, and where the reconstructed position quietly overstates what you owe. We now use that knowledge on the other side of the table, defending enterprises against the same tactics and negotiating renewals on terms that actually reflect your entitlements.
The practices above are the ones we help clients put in place, and they are the ones we lean on when a claim is already on the desk. We work on a shared savings model, which means we are paid only from the software cost we actually save you. There is no upfront fee, and if we do not find savings, you do not pay. If you want a second opinion on where your license position stands, or you have an audit letter in hand right now, start here. You can also see how we run this as a service on our software asset management page.
Frequently asked questions
What are IT asset management best practices?
The practices that matter most are keeping one authoritative record of your estate, reconciling your license entitlements against actual deployments rather than just tracking what is installed, covering the whole estate including cloud and SaaS, tying your review calendar to renewal and audit dates, treating your entitlement position as the defensible artifact, and assigning clear ownership of the reconciliation between the team that runs the tools and whoever holds the contracts.
What is the difference between ITAM and SAM?
IT asset management, or ITAM, covers the full estate of hardware and software across its lifecycle. Software asset management, or SAM, is the part of ITAM focused on software licenses, entitlements, and compliance. SAM is where audit risk and most recoverable cost live, which is why it gets disproportionate attention when a publisher comes calling.
Which ISO standard covers IT asset management?
The ISO/IEC 19770 family is the international standard for IT asset management. Part 1 sets out a framework of ITAM processes an organization can be measured against, part 2 defines software identification tags for what is installed, and part 3 defines a schema for software entitlements. The split between part 2 and part 3 mirrors the reconciliation at the heart of audit defense: what you have deployed versus what you are entitled to run.
Why isn’t a list of installed software enough for an audit?
An install list tells you what is running, not what you are allowed to run. A publisher audit compares your deployments against your entitlements and bills you for the gap. If you cannot produce your entitlement position, the contracts, amendments, true-up history, and product use rights that prove your allowance, the publisher’s version of your position becomes the one that counts.
How often should you reconcile entitlements against deployments?
Run a light reconciliation continuously as deployments change, and a full reconciliation ahead of every renewal and every known audit window, ideally 90 to 120 days before the date. The point is to know your position before the publisher does, so you enter any conversation with numbers you can defend rather than numbers you are seeing for the first time.
Does ITAM need to include cloud and SaaS?
Yes. Cloud subscriptions, SaaS seats, and hybrid deployments are where modern waste and modern audit exposure both concentrate. An ITAM program that stops at on-premise servers and desktops misses the largest and fastest-moving part of most estates, including unused SaaS seats and cloud services that keep billing after the need for them is gone.
Source notes
- ISO/IEC 19770 (Wikipedia): overview of the ISO/IEC 19770 family, including part 1 as a framework of ITAM processes, part 2 as software identification tags, and part 3 as a software entitlement schema.
- ISO/IEC 19770-1 (ITAM Standards, JTC 1 SC7 WG21): the standards body page describing 19770-1 as a framework of ITAM processes an organization can be measured against, applicable across cloud and other environments.
- Key Stages of the IT Asset Management Lifecycle (Flexera): the five-stage ITAM lifecycle of planning, acquisition, utilization, maintenance, and renewal or disposal referenced in the calendar section.