Direct answer: An application inventory is a record of every business application in your organisation, with its versions, the devices it is installed on, its owner, its dependencies and its vulnerability status. To create one, pull install data from the systems that already know (Intune, Configuration Manager), clean out runtimes, drivers and other noise, group variant names into one entry per product, then add owners and dependencies through interviews and procurement records. Keep it current by refreshing it from source on a schedule, not by repeating a one-off audit.
Most organisations already have something they call an application inventory. Usually it is a spreadsheet. It was accurate on the day someone finished it, and it has been drifting ever since.
An application inventory answers four questions about every business application you run: what is it, where is it, who owns it, and how risky is it right now.
It is not the same as a list of installed software. An export from your device management tool will tell you that thousands of distinct items are installed across the estate. Most of those are not applications anyone would put on a list: they are runtimes, drivers, language packs, update helpers and components that came bundled with something else.
It is also not the same as an asset register or a licence register. Those are useful, and an inventory often feeds them, but they answer different questions. The inventory is the operational view: the thing you reach for when an advisory lands, when a migration is planned, or when someone asks which devices still run an old version of a product.
Whatever tool you use, a working inventory needs six things for every application.
The figures below are illustrative, not drawn from a customer estate.
Notice what the table does not have: rows for the runtime the finance client needs, or for the driver the drawing tool installs. Those still matter, as dependencies, but they are not applications in their own right.
You can add more columns later, such as business criticality, cost centre or contract renewal date. Start with these six. They are the ones you will need most often, and the ones that go stale fastest.
No single source holds all six fields. A good inventory combines several, and is clear about which source is trusted for which field.
Device management (Intune). Intune’s discovered apps data tells you what is installed, at which version, on which managed device. It is the most reliable source for the first three fields. It has gaps, though, and it is worth knowing them before you rely on it. We cover those in detail in application discovery: what you’re missing in Intune today.
Configuration Manager (SCCM). If your estate is still on SCCM, or part-way through moving to Intune, its install data is just as valuable. Hardware and software inventory gives you applications, devices and the links between them. Building the inventory here first is often the sensible start of a move to Intune, because you only want to carry forward what the business still needs.
Interviews. Install data cannot tell you who owns an application, why an old version is still in place, or what breaks if it changes. Only people can. Short, structured conversations with department leads and service owners fill the owner and dependency fields and surface the exceptions nobody wrote down.
Procurement and contracts. Purchase records tell you what the organisation believes it has bought, and from whom. Comparing them with install data is a useful cross-check: applications that were bought but never show up, and applications that show up but were never bought, both need a conversation.
Vulnerability sources. Public databases such as the NIST National Vulnerability Database list known vulnerabilities by product and version range. Matching them against your inventory is what turns a list into a risk view.
The most common mistake is to export installed software, sort it alphabetically and call it the inventory. It looks complete. It is not usable.
It is full of things that are not applications. Runtimes, redistributables, device drivers, help files, installers left behind after setup, and components that came inside a bundle all register as installed software. Count them and your inventory inflates with noise, and the real business applications get buried.
The same product appears under several names. A vendor renames an edition. A language pack registers separately. Two installers leave slightly different display names. Unless these variants are grouped into one application family, you will overcount the number of products and undercount the versions of the ones that matter.
Look-alikes get merged by mistake. The opposite problem is just as costly. An add-in for a collaboration tool is not the tool itself. Merge them and the add-in’s version numbers get confused with the main product’s, which throws off vulnerability matching.
It says nothing about owners or dependencies. Install data is a starting point for the first three fields only.
So the order matters: collect, then clean, then group, then enrich. Measuring anything before the inventory is clean, such as how many versions of each product you run, gives you numbers you cannot defend. The version debt and application sprawl article shows what you can measure once the families are right.
This is where the manual approach breaks down. A spreadsheet inventory is a snapshot. The estate keeps changing after the snapshot is taken: devices are rebuilt, applications are updated, new versions arrive, and new vulnerabilities are published against versions that looked safe last month.
The usual response is a periodic audit. Someone re-runs the export, re-does the cleaning by hand, and tries to carry the owners and notes across from the old spreadsheet. Each round costs nearly as much as the first, and the cleaning decisions are rarely made the same way twice.
Three habits keep an inventory accurate instead.
For organisations planning a Windows 11 move, this is not optional. Migration programmes tend to stall on applications rather than the operating system, as we set out in why Windows 11 programmes fail on apps, not the OS. A current inventory is the first thing those programmes need.
ALICE follows the same method, and keeps it running after the first pass. It works with Microsoft Intune estates, and can also start from SCCM.
The result is an inventory that is refreshed from source, cleaned the same way each time, and connected to what you do next: rationalise, package and deploy through your own Intune.
If step nine is the hard one, that is the sign the spreadsheet has reached its limit.
An application inventory is only useful while it is true. Building it once is a project. Keeping it accurate is a process, and that is the part worth automating.
Start a 14-day ALICE trial, connect your Microsoft environment and see your estate grouped into application families, with versions, devices and vulnerabilities in one place.
ALICE is Camwood‘s platform for Autonomous Application Lifecycle Management: discover, rationalise, package, deploy and patch through your own Intune, with every decision kept on one record.
