Configuration Item (CI)

A Configuration Item (CI) is any IT estate component tracked in a CMDB because a change, loss, or misconfiguration of that component would impact an IT service. It is the atomic unit of configuration management in ITIL — the building block underlying every ITSM, ITAM, and SecOps practice.

A CI can be an application, a server, a workstation, a license, a contract, a database, a Kubernetes cluster, a business service, a runbook. The precise definition of a CI — its granularity, attributes, and relationships — is one of the most structural (and most neglected) decisions in any CMDB program.

CI types

ITIL 4 distinguishes four main CI families:

• •Hardware CIs: servers, storage arrays, network gear, user workstations, printers.
• •Software CIs: applications, operating systems, middleware, containers, firmware.
• •Service CIs: business services, SaaS subscriptions, outsourced services.
• •Documentation CIs: runbooks, contracts, SLAs, architecture diagrams.

This typology is extensible: some organizations add people CIs (owners, teams), business process CIs, or regulatory CIs.

Attributes and relationships

Each CI carries two types of information:

• •Attributes: own characteristics (name, version, owner, criticality, data classification, commissioning date, associated contract).
• •Relationships: links to other CIs ("runs on", "depends on", "connected to", "supports the service"). This network of relationships is what turns a flat list into an exploitable graph.

A critical business application can have dozens of relationships: VMs, databases, consumed APIs, owning teams, vendor contracts, supported business processes.

Granularity: the hardest decision

The granularity choice for CIs is the most important arbitration in a CMDB program:

• •Too coarse: (1 CI = 1 entire ERP): impact analysis loses precision.
• •Too fine: (1 CI = 1 ephemeral Kubernetes container): impossible to maintain manually.
• •Good compromise: a granularity level per CI class, documented in a modeling policy.

Practical rule: granularity should allow answering the business question "if this CI goes down, what stops?" — no more, no less.

CI vs Asset

• •An asset (ITAM) is tracked for its financial and contractual dimension (cost, owner, contract, depreciation).
• •A CI is tracked for its operational dimension (relationships, configuration, service impact).
• •A same physical element can be both asset and CI (a server), but not always (a contract is an asset but rarely a relevant CI; an ephemeral Kubernetes cluster may be a CI but not an asset).

Modern platforms unify both views in a single graph to avoid double entry.

CI lifecycle

A CI typically follows ITIL states:

• •Planned: acquisition decision taken.
• •Ordered: purchase in progress.
• •In stock: received but not deployed.
• •In production: active and used.
• •In obsolescence: flagged but still in service.
• •Retired: decommissioned.
• •Destroyed: gone from the IT estate.

State transitions are tracked in the CMDB and feed technical obsolescence analysis.

Source of truth and quality

The central challenge of a CI is not its creation but its freshness. A manually entered CI drifts from reality within weeks. Best practices:

• •Automatic source: every CI class must have an automatic discovery source (cloud API, SSO, endpoint agent, network scan).
• •Clear owner: each CI has a named business or technical owner.
• •Last-verified date: a CI without an update in 90 days is probably stale.
• •Confidence score: a metadata field that indicates data reliability.

Kabeen rebuilds the application CI graph automatically from agents, SSO, expense data, and user feedback — eliminating the manual data entry that is the number one cause of CMDB failure.