Updated 5 November 2026 · By Chris Hodder, CEO and Founder, CIH Solutions
In short: an asset is anything with financial value. A configuration item (CI) is anything you need to manage to deliver a service. In practice, the difference comes down to relationships: if it fails and one person notices, it’s an asset. If it fails and a service goes down, it’s a CI.
The difference between an asset and a CI is one of the most common misunderstandings in ITSM.
It’s an easy mistake to make. Many ITSM toolsets store assets and CIs in exactly the same way, in the same place, with the same relationship options. So it’s tempting to assume they’re the same thing.
But, and this is crucial, they aren’t. Treat them as though they are, and you’ll waste a lot of time and resources.
The Textbook Answer
ITIL 4 defines the two like this:
- IT asset: ‘any valuable component that can contribute to the delivery of an IT product or service’
- Configuration item: ‘any component that needs to be managed in order to deliver an IT service’
Those definitions are correct. In our experience, they’re also where most CMDB projects start to go wrong, because they treat every valuable component as a candidate for the CMDB. They don’t tell you where to focus your effort, so the rest of this article does.
| Asset | Configuration item (CI) | |
|---|---|---|
| What it’s about | Cost, ownership and lifecycle | Service delivery and dependencies |
| The question it answers | Who owns it, and where is it? | What breaks if this fails? |
| Where it usually lives | Asset register | CMDB |
| Process it mostly feeds | Incident management | Change and problem management |
| Relationships needed | An owner and a location | Other CIs, users and groups |
Why Draw a Distinction?
Your ITSM toolset makes no distinction between the two. That isn’t a flaw. It means the line between an asset and a CI isn’t a property of the device; it’s a decision you make, based on what matters to your services.
So why not simply treat them as the same thing?
Simple: you’ll waste a huge amount of time, and in all probability your CMDB project will stall before your ITSM toolset ever works the way you intended.
Take an example. Your organisation has 8,000 devices, each stored in your ITSM toolset as either an asset or a CI:
- 7,500 are workstation devices: PCs, laptops, printers, smartphones and so on.
- 500 are core infrastructure: servers and other devices that relate directly to your data centre.
All of these devices have relationships of some sort. So which should you prioritise?
Often, organisations become obsessed with defining relationships for every single PC, laptop and smartphone. But that’s crazy. It takes a huge amount of time and resources and achieves very little, because a single faulty PC only impacts one user.
A faulty server, on the other hand, could impact the entire organisation. That’s precisely why the distinction matters. Focus your time and resources on defining relationships for the 500 important devices, and you’ll dramatically improve the value of your ITSM toolset.
The Difference in a Nutshell
Our shorthand is simple: CIs have relationships, assets don’t.
Strictly speaking, an asset has a couple (an owner and a location), but they’re attributes you record, not dependencies you maintain. A CI’s relationships to other CIs, users and groups are what make it useful:
- An asset must have an owner and a location… and that’s about it.
- A CI needs a whole range of relationships to be useful, including to other CIs, users and groups.
Back to our example. The 7,500 PCs, laptops and smartphones are assets: we need to know where they are and who owns them, but that’s about it. The other 500 devices need a far more comprehensive set of relationships for your ITSM toolset to function properly. So we make a deliberate choice: those 500 become CIs, and that’s where most of the effort goes, defining their relationships and keeping that data accurate.
The One-User Test
Not sure which side of the line something sits on? Ask one question: if this fails, who notices?
- One person: track it as an asset. Owner and location, and you’re done.
- A team, a department or your customers: make it a CI and map its relationships properly.
It’s a simple question, and it settles most cases before anyone opens a spreadsheet. For a fuller checklist, see our guide to working out which assets should become CIs.
Asset, CI, or Both?
Some items are both, and some are only one:
- Both: a production server. It has a cost and a lifecycle, and services depend on it.
- Asset only: a spare monitor, a docking station or a software licence.
- CI only: a VLAN, a cluster or a business service. Services depend on these, but they don’t carry value on the balance sheet.
That last group catches people out. Build your CMDB purely from your asset register and you’ll miss the things that cause the biggest outages.
Incident Management vs Change Management
Another way to see the difference is through the processes each one feeds. Assets mostly fall under incident management. CIs matter most in change management.
An asset is typically an endpoint device used by a single user. If a fault occurs, the user reports it, and an incident is raised to fix or replace the asset.
CIs are far more complex. Imagine you need to install a new version of an important application on a server that also hosts several other applications. To plan that change effectively, the server needs a full set of defined relationships, so you can see which services the update could affect and avoid a major disruption.
At its heart, this is the distinction between an asset and a CI. There’s almost no scenario in which a desktop PC fault could cause major disruption to your organisation, or impact more than a handful of users. There are few scenarios in which a fault with an important server wouldn’t.
Frequently Asked Questions
What is a CI in ITSM?
A configuration item is any component you need to manage to deliver an IT service, such as a server, an application or a network component. CIs are recorded in a CMDB with their relationships, so you can see what’s affected when something changes or fails.
What’s the difference between asset management and configuration management?
Asset management tracks the financial side: what you own, what it cost and where it is. Configuration management tracks how components fit together to deliver services. They overlap, and they work best when they share data.
Do ITSM tools treat assets and CIs differently?
It depends on the platform. Some store them as the same type of record, and others keep separate, linked records. Either way, deciding what counts as a CI is down to you.
How do I decide which assets should become CIs?
Start with the one-user test. If something supports a critical service, needs change tracking or has dependencies, it’s a strong candidate for a CI.
Soothing the ITSM Headache
Laying your ITSM groundwork can be a long, difficult process, and getting it wrong can cause huge problems down the line. Properly distinguishing between assets and CIs, and defining relationships appropriately, is a big part of getting it right.
