What is the difference between ITSM and ITAM?

ITSM covers the processes for delivering and supporting services, such as incident, request, and change management, and its records are units of work. ITAM tracks the assets an organisation owns across their lifecycle, including cost, ownership, licences, and expiry dates, and its records are objects.

Is a CMDB part of ITSM or ITAM?

It sits between them. A configuration database holds objects and their relationships so that service processes can use them, which makes it ITAM-shaped data consumed for ITSM purposes. That dual role is why ownership of it is so often unclear and why it tends to go stale.

Why does asset inventory data go stale?

Because it is usually maintained by people remembering to update it, and nothing visibly breaks when they forget. Inventories that stay accurate are reconciled against automated discovery: network scans, endpoint agents, and cloud billing. The disagreements between discovery and procurement records are the useful output.

Does ITAM matter for security?

Yes, in two specific ways. Devices on the network that appear in no asset record are unmanaged and usually unpatched. And recording end of support dates tells you where unfixable vulnerabilities will accumulate, which is a prediction available years ahead of any exploitation.

ITSM vs ITAM

IT service management covers the processes for delivering and supporting services, including incidents, requests, and changes. IT asset management tracks the hardware, software, and licences an organisation owns across their lifecycle, including cost, ownership, and expiry. ITSM manages work; ITAM manages the things that work is performed on.

Two different questions

ITSM asks whether the service works and what is being done about it. Its records are events and activities: an incident opened, escalated, resolved; a change requested, assessed, deployed. The unit is a piece of work with a start and an end.

ITAM asks what exists. Its records are objects with a lifecycle measured in years: a server procured, racked, maintained, decommissioned; a licence purchased, allocated, renewed, retired. The unit is a thing you own or are entitled to, and the interesting facts about it are ownership, cost, and dates.

The practical distinction is what makes each one wrong. An ITSM tool with no asset data can tell you a laptop generated eleven tickets and not that it is four years past its refresh date or that its operating system stopped receiving patches. An ITAM system with no service data can tell you that you own three hundred of a device and not that one model accounts for most of the support load.

Where the configuration database sits

A configuration management database is the attempt to hold the objects and their relationships in a form service processes can use: this service runs on these hosts, which depend on that database, which sits behind this load balancer. It is genuinely valuable during an incident, because it answers what else is affected. It is also the component most likely to be stale, because it decays silently. Nothing breaks when a relationship becomes wrong; it just quietly misleads the next responder who trusts it.

Why asset data decays, and what to do about it

Manual entry loses to reality. Anything maintained by people remembering to update it drifts, because the update is unrewarded and its absence is invisible. The only durable inventories are the ones that reconcile against automated discovery: what the network sees, what the endpoint agent reports, what the cloud provider bills you for.

Reconcile rather than overwrite. Discovery finds what is running. Procurement records what was bought. The interesting rows are the disagreements: assets in procurement that discovery never sees, and devices on the network that appear in no record. Both are findings. A process that lets one source silently overwrite the other destroys exactly that signal.

Cloud broke the asset model that hardware fit. An instance that exists for nine minutes is not an asset in the sense a laptop is, and trying to track it as one produces noise. The stable objects in cloud environments are accounts, subscriptions, and the definitions that create resources, and cost allocation replaces physical location as the ownership signal.

Licences are the part that bites financially. Entitlement counts, allowed use, and renewal dates live in contracts, not in discovery data, and the gap between what is deployed and what is entitled is only visible when both halves exist.

End of support dates are a security input. Inventory that records when a platform stops receiving patches tells you where unfixable vulnerabilities will accumulate. That is a prediction you can act on before anything is exploited, and it is usually available years in advance.

The join that makes both useful

Reference the asset on the ticket. If incidents, changes, and requests carry an asset or service reference, you can aggregate work by object. That is what turns support load into a procurement argument: this model, this version, this site accounts for a disproportionate share of the queue.

Reference the service, not only the device. Users experience services. Tying a ticket only to a laptop loses the fact that thirty tickets across thirty laptops were all one broken service.

Use asset context during incidents. Firmware version, patch level, warranty state, and dependencies change what the responder tries first. Making that context one click from the ticket is worth more than a richer data model nobody opens.

Let retirement decisions use both sides. A refresh decision made on age alone ignores that some old hardware is reliable and some new hardware is not. Age plus incident history is a better signal than either.

Accept that scope creep kills these projects. An inventory limited to the classes of asset you will actually make decisions about, kept accurate, beats a comprehensive one that is wrong. Pick the subset where a decision depends on the data, and reconcile that.

Dimension	ITSM	ITAM
Centre of gravity	Work: tickets, incidents, changes	Objects: devices, software, licences, contracts
Key question	Is the service working, and who is on it	What do we own, where is it, what does it cost
Lifecycle tracked	The lifecycle of a request or incident	Procure, deploy, maintain, retire, dispose
Primary metrics	Time to restore, backlog, satisfaction	Utilisation, licence compliance, total cost, refresh due
Data source	People reporting and telemetry	Discovery scans, procurement records, contracts
Typical owner	Service desk and operations	IT finance, procurement, or asset team
Security relevance	Incident response and change control	End of support and unpatchable inventory
Common failure	Tickets with no asset reference	An inventory nobody reconciles

Frequently asked questions

What is the difference between ITSM and ITAM?: ITSM covers the processes for delivering and supporting services, such as incident, request, and change management, and its records are units of work. ITAM tracks the assets an organisation owns across their lifecycle, including cost, ownership, licences, and expiry dates, and its records are objects.
Is a CMDB part of ITSM or ITAM?: It sits between them. A configuration database holds objects and their relationships so that service processes can use them, which makes it ITAM-shaped data consumed for ITSM purposes. That dual role is why ownership of it is so often unclear and why it tends to go stale.
Why does asset inventory data go stale?: Because it is usually maintained by people remembering to update it, and nothing visibly breaks when they forget. Inventories that stay accurate are reconciled against automated discovery: network scans, endpoint agents, and cloud billing. The disagreements between discovery and procurement records are the useful output.
Does ITAM matter for security?: Yes, in two specific ways. Devices on the network that appear in no asset record are unmanaged and usually unpatched. And recording end of support dates tells you where unfixable vulnerabilities will accumulate, which is a prediction available years ahead of any exploitation.