What Is a Configuration Item (CI)?

A configuration item (CI) is any component that needs to be managed in order to deliver an IT service - a server, an application, a network switch, even a document - recorded in a configuration management database (CMDB). The term comes from ITIL, the most widely used IT service management framework. What separates a CI from an ordinary asset record is the relationship data: a CMDB does not just list components, it maps how they depend on one another, so that when something fails, the blast radius is visible.

Examples of configuration items

• Hardware CIs - servers, network switches, routers, firewalls, storage arrays, and end-user devices where a service depends on them.
• Software CIs - operating systems, applications, databases, middleware, and their versions.
• Documentation CIs - runbooks, SLAs, network diagrams, and policies that the service cannot be operated without.
• Service and infrastructure CIs - the email service itself, cloud instances, SSL certificates, DNS zones.

The defining test is service impact, not price. A cheap SSL certificate is a textbook CI because its expiry takes a service down; an expensive item with no service role - spare external drives in a cupboard, or the conference room equipment nobody’s uptime depends on - is an asset worth tracking, but rarely worth modelling as a CI.

What a CI record contains

A CI carries a unique identifier, a type, an owner, a status, and a version where one applies. The attribute that does the real work is relationships: “runs on”, “depends on”, “connects to”, “is documented by”. Those links are what let a service desk trace an outage from the failed switch to the three applications behind it, or assess in advance what a planned change will touch. Strip the relationships away and a CMDB collapses into an ordinary inventory with extra fields.

CI vs asset

The two concepts describe the same physical world from different angles. An asset record takes the ownership and financial view: purchase price, supplier, warranty, current holder, position in the IT asset lifecycle, and when the hardware refresh cycle says it should be replaced. A CI takes the service view: what this component supports and what happens if it fails.

The sets overlap without matching. A production server is both an asset and a CI. A spare monitor is an asset but no CI. A free open-source library or a runbook is a CI but appears on no balance sheet - just as a software entitlement is an asset in licence terms whether or not anyone models it in a CMDB.

When a CMDB is overkill

CMDBs have a well-earned reputation for decay. Relationship data is expensive to keep current - every architecture change, migration, and decommission has to be reflected, and a CMDB that is 80% right is dangerous precisely because people trust it mid-incident. The honest sizing rule: model CIs where the dependency mapping will genuinely be maintained and consulted, usually the servers, network gear, and core applications behind critical services. For everything else - and for most small and mid-size organisations entirely - a well-kept asset register with owners, statuses, and history delivers most of the value at a fraction of the upkeep; the glossary covers the register-side concepts in depth.

Related terms

• IT Asset Lifecycle - the purchase-to-disposal stages the asset view tracks
• Hardware Refresh Cycle - the planned replacement rhythm for hardware CIs and assets
• Software Entitlement - the licence rights behind software CIs
• Perpetual vs Subscription License - the two ways software CIs are paid for
• Per-User Licensing - seat-based licensing tied to users rather than components