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.

What you will learn

• Configuration item: the short definition
• What CI stands for (and what it does not)
• CI types with subtypes
• What a CI record contains
• CI relationship types
• The CI lifecycle
• How to decide what becomes a CI
• Where CI data comes from
• Keeping CI records trustworthy
• CI vs asset vs inventory record
• Do you actually need a CMDB?
• FAQ

Configuration item: the short definition

CI = configuration item. ITIL defines it as any component that needs to be managed in order to deliver an IT service. ISO/IEC 20000 frames the same idea as any element that must be controlled to deliver a service. The practical test: if a change to it can affect service delivery, availability, security or compliance, it is a configuration item.

That test is deliberately blunt, because the alternative tests people reach for - “is it expensive?”, “did we capitalise it?”, “is it physical?” - all produce the wrong list. A £4 domain renewal is a CI. A £900 spare monitor in a cupboard is not.

What CI stands for (and what it does not)

In IT service management, CI means configuration item - the sense used throughout this page.

In software delivery, CI means continuous integration - the automated build-and-test stage of a CI/CD pipeline. It has nothing to do with CMDBs. This is why the bare abbreviation is ambiguous in any conversation that spans developers and operations, and why platform teams tend to say “config item” out loud to disambiguate.

In systems and defence engineering, a configuration item is something older and stricter: an aggregation of hardware and/or software designated for separate configuration management and formally controlled against a baseline. You will see hardware configuration items (HWCI), computer software configuration items (CSCI), interface CIs and COTS CIs, tracked across functional, allocated and product baselines with change boards approving each revision. Same phrase, different discipline - and a common source of confusion when engineering and IT teams share a vocabulary but not a definition.

CI types with subtypes

Most CMDBs organise CIs into a class hierarchy so that shared attributes and rules are inherited rather than re-entered. The usual top-level classes:

• Hardware and infrastructure CIs - physical and virtual servers, storage arrays, load balancers, hypervisors, printers, and the laptops and other endpoints a service genuinely depends on.
• Software and application CIs - operating systems, business applications, middleware, databases, container images, and SaaS tenants, each with a version.
• Network CIs - routers, switches, firewalls, VLANs and subnets, DNS records, VPN tunnels, wireless access points, and the rest of your networking equipment.
• Cloud and platform CIs - managed database instances, Kubernetes clusters, storage buckets, IAM roles, message queues, and the accounts or subscriptions they live in.
• Service CIs - the customer-facing service itself (“payroll”, “email”), plus APIs and interfaces between services.
• Documentation CIs - runbooks, network diagrams, SLAs and OLAs, installation guides, and the golden image definitions builds are cut from.
• Facility CIs - server rooms, UPS units, PDUs, HVAC, and physical access control where an outage in them takes IT down with it.
• Supplier and contract CIs - the vendor, support contract, or software entitlement that a service legally or practically relies on.

Some models also register people and roles as CIs, so that “who is accountable for this” appears in the dependency map rather than in someone’s head. The defining test throughout 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 useful CI record is short and complete rather than long and half-filled. The fields nearly every CMDB expects:

• Unique CI identifier - a stable asset ID that survives renames and re-IPs.
• Name - a human-readable label following a documented naming standard.
• Type or class - where it sits in the class hierarchy.
• Status - active, in maintenance, inactive, retired.
• Environment - production, staging, test, development.
• Owner - a named person or team accountable for it.
• Version, model or build - for anything that is patched or upgraded.
• Location - data centre, site, cloud region, or account.
• Serial number or instance ID - the manufacturer or platform reference.
• Supplier and support contract - who you call, and until when.
• Related service - the business service this component ultimately supports.
• Relationships - the links to other CIs, covered next.
• Change history - an audit trail of what changed, when, and by whom.

Resist the urge to add more. Every attribute is a field someone must maintain, and the fastest way to make a CMDB untrustworthy is to fill it with columns nobody reads.

CI relationship types

Relationships are the attribute that does the real work. Strip them away and a CMDB collapses into an ordinary IT inventory with extra fields. Most models group them into four families:

• Dependency - “runs on”, “depends on”, “uses”. The application depends on the database.
• Containment - “hosted by”, “part of”, “member of”. The VM is hosted by the hypervisor; the disk is part of the array.
• Ownership - “owned by”, “supported by”, “managed by”. Links a CI to a team or person.
• Impact - the derived view: what fails downstream when this fails.

A worked chain makes the point. Access switch → hypervisor host → virtual machine → database instance → payment service. When the switch drops, that single link lets the service desk name the payment service in seconds instead of waiting for customers to report it. Read the same chain in the other direction and it becomes a change impact assessment: patching the hypervisor means scheduling around payments. Read it a third time and it becomes risk and compliance scope - everything in that chain is in scope for the controls that protect payment data.

Those are three different jobs served by one set of links, which is exactly why relationship data is worth the upkeep where it is genuinely maintained, and worthless where it is not. The same principle drives asset hierarchy modelling on the register side, at a much lower cost.

The CI lifecycle

A CI record has a life of its own, running roughly in parallel with the IT asset lifecycle:

1. Plan and design - the component is specified; a CI class and naming convention are chosen.
2. Procure or build - purchased, provisioned, or compiled.
3. Identify and register - a unique CI ID is assigned and the record is created. This is the step teams skip, and everything downstream inherits the gap.
4. Test - verified against its intended configuration or baseline.
5. Deploy - moved into production, with relationships recorded as they are made.
6. Early life support - watched closely; the record is corrected while the details are still fresh.
7. Live - in service, with every change reflected in the record.
8. Retire and dispose - status set to retired, relationships unpicked, and the physical or contractual end handled through asset decommissioning and IT asset disposition.

Each stage maps to a status value the record actually carries: active, in maintenance, inactive, retired. A status field nobody updates is the first part of a CMDB to rot, and retired-but-still-linked CIs are the most common cause of a dependency map that quietly stops matching reality.

How to decide what becomes a CI

Four questions, in order:

1. Does a change to it need to be reviewed or audited? If a change goes through a change board or lands in a compliance report, model it.
2. Does its failure affect a service users would notice? If yes, its dependencies are worth mapping.
3. Does anyone actually own it? A CI with no named owner is a record with no maintainer.
4. Will the record be kept current? If the honest answer is no, do not create it.

Then set granularity: use the least detailed classification that answers your questions. Every extra level of detail multiplies upkeep without necessarily improving decisions. “Database server” as one CI is often enough; splitting it into chassis, RAID controller, and individual disks rarely is, unless you replace those parts independently.

For cloud and ephemeral resources, model the stable template rather than each short-lived instance - the autoscaling group, not the forty containers it spawned this afternoon; the function definition, not each invocation environment. Tagging discipline in the cloud account does more for you here than any amount of instance-level modelling. And the rule that governs all of it: do not model what you will not maintain.

Where CI data comes from

CI records get created and kept current three ways, usually in combination.

Manual registration happens at purchase or deployment. It is the most accurate route for anything that has no API - facility CIs, documentation, supplier contracts - and the most fragile, because it depends entirely on someone remembering.

Bulk import brings in what already exists in spreadsheets, purchase records, or another system. It is how most registers start, and it is fine as a starting point provided the data is cleaned before it lands rather than after.

Automated discovery queries the environment directly. Agentless discovery reads from cloud provider, virtualisation and network APIs; agent-based discovery installs software on hosts for deeper detail such as installed packages and running processes. Continuous sync beats a weekly job, because a CMDB that is a week behind is exactly as misleading as one that is a year behind during the incident where it matters. Asset discovery covers the market landscape in more detail.

The important caveat: automation solves collection, not structure. Discovery tells you a machine exists; it cannot tell you which business service it supports, who owns it, or whether the duplicate it just created is really a separate host. Classification, ownership and review rules stay human work, which is why fully discovered CMDBs still decay - and why undiscovered corners like shadow IT stay invisible either way.

Keeping CI records trustworthy

A partly-correct CMDB is more dangerous than no CMDB, because people trust it mid-incident. The maintenance discipline that prevents that:

• Standardise naming and key fields. One naming convention, documented, applied at creation. Retro-fixing names is miserable work.
• Assign a named owner per CI or per class before an incident exposes the gap, not during one.
• Reconcile duplicates and orphans on a schedule. Discovery creates duplicates; decommissions leave orphans. Asset reconciliation is the routine that catches both, and it is how ghost assets - records for things that no longer exist - get cleared out.
• Limit attributes to fields someone actually reads. Unused fields do not stay empty; they fill with plausible nonsense.
• Record changes as they happen, not in an annual clean-up. The annual clean-up is where CMDB projects go to die.

Ownership matters at the process level too: a configuration manager owns the standards and the audits, service owners are accountable for the CIs behind their services, and operations reflects real-world change into the records. Without those three roles, data quality is nobody’s job.

CI vs asset vs inventory record

The three describe the same physical world from different angles.

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.

The clearest illustration is a single VM. In ITAM it is a cost centre, a licence consumer, and a line on a depreciation schedule, with a position in the hardware refresh cycle behind it. In the CMDB, the same VM is a node with four links to other nodes. Neither view is the whole picture, and neither is a substitute for the other.

Do you actually need a CMDB?

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.

Signals you need one: interlocking services where one component supports several others; formal change control with a review board; regulated uptime or audit obligations; and an ops team large enough that nobody holds the whole map in their head any more.

Signals a well-kept asset register is enough: a few dozen endpoints; a handful of SaaS tenants; one or two people doing IT; and dependencies simple enough to draw on a whiteboard in ten minutes.

The middle path, which suits most organisations: start with an accurate register - owner, status, location, serial, history - and add relationship modelling only for the small set of components whose failure is genuinely expensive. That gets you most of the incident-response value without signing up for enterprise-scale upkeep. Start with a simple asset register walks through how to do that, and the CMDB entry covers what the full version involves if you decide you need it.

FAQ

What does CI stand for in IT?

It depends on the room you are standing in. In IT service management, CI stands for configuration item - a component tracked in a CMDB because a service depends on it. In software delivery, CI stands for continuous integration, the automated build-and-test step in a CI/CD pipeline. The two are unrelated, so in mixed dev and ops conversations it is worth saying which one you mean.

What is a configuration item in ITIL?

ITIL defines a configuration item as any component that needs to be managed in order to deliver an IT service. In ITIL 4 this sits under the service configuration management practice, whose job is to keep accurate information about CIs and the relationships between them. The records live in one or more CMDBs, and the practical test is unchanged - if a change to the component can affect a service, it is a CI.

What is the difference between a configuration item and an asset?

An asset record answers ownership and money questions - what it cost, who holds it, when the warranty ends. A CI answers service questions - what this component supports and what breaks if it fails - which is why CIs carry relationships to other CIs. The same server can be both. Many assets are never CIs (spare monitors, furniture), and some CIs are not financial assets at all (documentation, a free software library).

What is the difference between a CMDB and an asset register?

A CMDB stores configuration items and, crucially, the relationships between them, so you can trace what fails when a component fails. An asset register stores ownership, cost, location, status and lifecycle for the things you own. One VM can appear in both - as a depreciating cost line in the register and as a linked node in the CMDB. For most small and mid-size IT teams an accurate register delivers the bigger share of the value at a fraction of the upkeep.

What are examples of configuration items?

Hardware: servers, network switches, firewalls, the laptops a service depends on. Software: operating systems, applications, databases, middleware. Beyond that, anything managed in order to deliver a service: SSL certificates, cloud instances, runbooks and SLA documents, and the services themselves. Each CI carries an identifier, an owner, a status, a version where relevant, and its relationships to the CIs it depends on.

Does every asset need to be a CI?

No. CIs only earn their keep where the relationship data is actively maintained - a CMDB full of stale links is worse than no CMDB, because people trust it during incidents. The usual approach is to model only the components whose failure affects services (servers, network gear, core applications) as CIs, and keep everything else as plain asset records with an owner, a status, and a lifecycle.

Tools that make this easier

If the middle path is where you land, the job is an accurate register rather than a dependency graph. AMPthilly gives every item one record with a category and sub-category, a status (in use, in storage, in repair, retired), a current owner and location, serial number, supplier, purchase date and warranty end, plus custom fields per asset type for anything specific to your environment. Physical equipment, software licences and consumables live in the same register, you can CSV import what you already have and export it back out, printable QR labels open the right record from a normal phone camera in the browser with no app to install, and a permanent audit history records every checkout, return, transfer, status change and field edit. The free plan covers 3 users and 25 assets with no card required.

The takeaway

A configuration item is any component you must manage in order to deliver an IT service, identified by service impact rather than price, and made useful by the relationships recorded alongside it. Get the four fundamentals right - a unique ID, a named owner, a status somebody updates, and links that reflect reality - and the CMDB pays for itself in faster triage and safer changes. Get them wrong and it becomes a confident, out-of-date map that people follow into the wrong outage. If your environment is small enough that the dependencies still fit in one person’s head, start with a well-kept asset register and add CI modelling only where failure is genuinely expensive.

Related terms

• CMDB - the database where configuration items and their relationships live
• Asset Register - the ownership-and-money view that most teams need first
• 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