What Is a Configuration Item (CI)? Definition, Examples & CMDB Guide

On March 1, 2024, Microsoft went dark. It was a massive outage. Outlook, Teams, Exchange, and even Azure all went down.

Tens of thousands of users were locked out. Businesses stalled. Productivity froze mid-click.

One glitch sent a ripple across the entire Microsoft ecosystem.

And here’s the thing: figuring out what caused the outage put the ‘trust’ customers had placed in Microsoft under a microscope. Eventually, it was all sorted. But the initial blame went to CrowdStrike, its cybersecurity vendor.

This is what happens when IT systems stretch across hundreds of servers, apps, and networks. One weak link, and the whole chain snaps.

Downtime isn’t just annoying. It’s expensive. Some studies put it at $9,000 per minute. That’s a bleeding edge nobody wants to be on.

The problem? Most organizations can’t actually see all their moving parts.

Servers are here. Databases there. Software licenses are floating somewhere in the middle. All siloed, all critical, none fully mapped.

This is where the CMDB configuration item comes in.

Track every component. See the dependencies. Know the blast radius before something fails.

In this guide, we’ll break down what a configuration item is, the different types, and best practices to manage them. Your team can spend less time firefighting and more time running IT the way it should.

What is a configuration item in ITIL?

A configuration item (CI) is any component or resource in an organization’s IT environment that needs to be tracked and managed to deliver services. In ITIL configuration management, CIs are tracked for their existence, relationships, dependencies, and impact on services.

CIs can include:

• Physical assets like servers, network devices, and laptops
• Digital assets like applications, virtual machines, and cloud services
• Documentation such as policies, process diagrams, and service-level agreements
• People in roles such as service owners, administrators, or specialists
• Facilities like data centers, network rooms, or other service-critical locations

A CMDB stores detailed records about each configuration item and its connections. This helps IT teams:

• See how services depend on each other
• Assess the impact of changes before they happen
• Cut downtime by improving incident and problem resolution

Keeping CI records accurate within ITIL configuration management practices helps organizations make better decisions, reduce service disruptions, and align IT operations with business goals.

Types of configuration items in CMDB

In a configuration management database, a configuration item can be almost any component needed to deliver and maintain IT services. To simplify management, CIs are grouped into clear categories.

Configuration item categories in CMDB

Hardware CIs

Hardware Configuration Items include all physical devices in your IT environment: servers, laptops, desktops, routers, storage systems, and network switches. These are the tangible components that IT infrastructure runs on.

Software CIs

Software Configuration Items cover applications, operating systems, databases, middleware, and virtual machines, including those in cloud environments. Tracking software CIs helps teams understand what’s deployed, where it runs, and how it interacts with other components.

Documentation CIs

Documentation CIs include manuals, support guides, configuration diagrams, policies, and process documents. While intangible, they’re critical for troubleshooting, compliance, audits, and keeping operations consistent.

People CIs

People CIs capture the roles, responsibilities, and relationships of individuals managing or using IT services. System administrators, service owners, and support teams all fall into this category. Tracking people as CIs keeps accountability and operational clarity in check.

Facility CIs

Facility CIs include physical locations that support IT operations: data centers, server rooms, or disaster recovery sites. These are tracked because they provide the environment where IT services run.

Categorizing Configuration Items into hardware, software, documentation, people, and facilities gives organizations a structured view of their IT environment. That structure makes it easier to manage dependencies, relationships, and service impacts.

What are CI attributes, and what data should you track?

Every configuration item in your CMDB should carry a core set of attributes that describe what it is, where it sits, and how it connects to other components. Common CI attributes include the CI name, unique identifier, type/category, owner, location, version, status (active, retired, in test), and relationships to other CIs.

For hardware CIs, you’d also track serial number, manufacturer, model, warranty status, and IP address. Software CIs need version number, license type, vendor, and install location. The goal is to capture enough detail that any IT team member can understand the CI’s role in service delivery without digging through separate systems.

Start with the attributes that matter most for incident response and change management. You can expand the data model later as your CMDB matures.

Configuration item vs. IT asset: What’s the difference?

It’s common to confuse Configuration Items with IT assets. They serve different purposes in IT management.

An IT asset is any hardware, software, or resource with financial value for the organization. Think laptops, servers, software licenses, or cloud subscriptions. IT Asset Management focuses on costs, contracts, and lifecycle management.

A configuration item is about service delivery and operations. A CI could be an IT asset, or it could be something with no direct financial value, like documentation, a database connection string, or a virtual service dependency that directly affects IT service delivery.

Some items qualify as both assets and CIs. CIs focus on keeping services reliable. Assets focus on managing costs and ownership. Virima brings both views together by combining ITAM with CMDB and service mapping, so teams see financial and operational context in one place.

Why Configuration Items matter in ITSM processes?

Configuration Items are the building blocks of IT service management (ITSM).

From servers and cloud instances to business applications and supporting documentation, CIs give IT teams full visibility into the infrastructure powering business services.

CIs also form the operational spine of incident resolution, change impact analysis, problem prevention, and compliance. When managed through a CMDB, they help IT organizations turn raw data into insights that directly affect business continuity and cost control.

What happens when configuration item data in your CMDB is inaccurate?

Inaccurate CI data leads to blind spots during incidents, failed changes, and compliance gaps. If your CMDB shows a server running one application when it actually supports five, a routine patch can trigger an outage nobody predicted.

Stale CI records also undermine root-cause analysis. Teams waste time chasing the wrong dependencies and miss the actual failure point. Over time, trust in the CMDB erodes, and teams fall back on tribal knowledge and spreadsheets, which only makes the problem worse.

Automated IT discovery solves this by running recurring scheduled scans that continuously reconcile what is actually running against what is recorded in the CMDB. Instead of relying on manual updates, tools like Virima populate CI records from discovery-sourced CMDB data, so the record reflects the live environment.

d machine-learning-driven relationship mapping. ViVID™ service maps then present near-real-time views of dependencies, infrastructure, and service relationships for smarter ITIL-driven decisions.

Reducing downtime during outages: incident management

HealthSure Hospitals relies on Electronic Health Record (EHR) systems to provide patient information across departments. One morning, the EHR system slowed to a crawl.

The IT team used the CMDB to identify all dependent CIs: EHR application servers, database clusters, and network gateways. They quickly found that the database cluster supporting multiple clinical systems was near capacity. Using Virima, the team identified 12 servers supporting the application, far more than the four the vendor had documented. Resources were reallocated quickly, and the CMDB was updated with incident and corrective actions.

By maintaining accurate CI relationships, HealthSure resolved the outage in under 45 minutes.

Virima case highlight:

• Automated discovery of over 7,000 server configurations and 2,000 applications in this deployment
• Mapping of 150+ enterprise services so teams always know the full scope of dependencies

Configuration Items in Agentic IT

AI is no longer a passive recommendation engine. In agentic IT environments, AI agents approve change requests, route incident tickets, provision cloud infrastructure, and trigger remediation workflows without waiting for human sign-off at every step. Every one of those actions runs on CI data. That makes CI accuracy a governance requirement, not just an operational preference.

When an AI agent reads a CI record to evaluate change risk, it assumes that record reflects the current state of the environment. If the record is stale, showing a retired dependency or missing a new service relationship, the agent has no way to know that. It acts on what the record says. A stale CI that triggers a miscalculated blast radius analysis, an unowned CI that routes an incident to the wrong team, or a CI with no discovery provenance that an agent treats as authoritative: each failure now occurs at machine speed, not human speed. The blast radius of a bad CI record scales directly with automation.

Agentic IT operations require three specific CI governance properties that traditional CMDB practices do not enforce:

Ownership attribution. Every CI must have a clearly named owner. When an agent escalates, routes, or gates approval, it needs a human who is accountable for that CI’s accuracy and the decisions it drives.

Discovery provenance. Every CI record must document where its data came from, when it was last discovered, and whether the discovery method is authoritative for that CI class. An agent that acts on a CI record without provenance visibility is acting on unverified data.

Policy embedding at the CI level. Governance rules, such as who can modify this CI, which change windows apply, and what compliance scope it falls under, must live at the CI record itself, not in a separate policy layer an agent might bypass.

Virima addresses all three through discovery-sourced trusted runtime truth. Our automated discovery builds CI records from authoritative multi-source scheduled scans, not manual entry. Each CI carries provenance from its discovery source. CMDB health scoring surfaces records that are stale, unowned, or incomplete before an agent acts on them. CI lifecycle tracking ensures ownership is assigned from the moment a CI enters the environment. When AI agents need to act, they need CI records they can trust, and Virima’s trusted runtime truth layer delivers exactly that.

Configuration item (CI) lifecycle in ITIL 4

Managing the configuration item lifecycle ensures accurate records, better control, and efficient service delivery across ITSM processes like change enablement, incident response, and problem management.

Planning and design

This stage starts with identifying the business need for a new CI. IT and business stakeholders decide what type of configuration item is needed (server, application, database, etc.) and define its specifications, expected relationships, and compliance requirements. Clear goals set upfront prevent unnecessary complexity and ensure each CI adds real value to IT services.

Acquisition and procurement

Once requirements are defined, the CI is purchased, licensed, or developed according to the agreed design. This may involve vendor negotiations, cost approvals, and alignment with security or architectural standards. The procurement stage is also where IT Asset Management records the financial data that will track the CI’s cost over its lifecycle.

Identification and registration

IT teams must uniquely identify every configuration item before it enters the live environment. This includes assigning a unique CI ID, categorizing the CI type (hardware, software, documentation, people, or facilities), and documenting attributes such as version, owner, location, and relationships in the CMDB. This ensures traceability and links the CI to incidents, changes, or service requests later in its lifecycle.

Testing and quality assurance

IT teams place the CI in a test or staging environment before deployment. They validate whether it meets performance, security, and compliance requirements. This step prevents flawed configurations from reaching production and reduces the risk of service disruptions.

Deployment to production

The CI moves into the production environment following change management approvals. Deployment includes documenting the go-live date, dependencies, and rollback plans in case issues arise after release.

Early life support (ELS)

During the initial post-deployment phase, the CI gets enhanced monitoring and support. This hypercare period helps IT teams quickly address unexpected issues and stabilize performance before steady-state operations begin.

Production and operational management

The CI now operates as part of the organization’s live IT services. At this stage, IT teams handle performance monitoring, apply patches and updates to keep the CI secure and compliant, and record incidents and changes linked to the CI for accurate impact analysis. Recurring scheduled discovery scans maintain accuracy by detecting configuration drift and refreshing CI records with discovery-sourced CMDB data.

Continuous review and optimization

Throughout its lifecycle, the configuration item undergoes periodic audits and reconciliations to ensure data accuracy and regulatory compliance. Outdated relationships or unauthorized changes are corrected to maintain CMDB reliability. Virima’s CMDB health scoring surfaces staleness and ownership gaps before they affect service delivery or expose AI agents to untrustworthy data.

Retirement and disposal

When the CI becomes obsolete or is replaced, it moves into retirement. This involves safely removing sensitive data, redeploying or canceling software licenses, recycling or securely disposing of hardware, and updating the CMDB to reflect the CI’s removal and prevent ghost dependencies. Proper retirement ensures cost savings, compliance with data privacy regulations such as those outlined in the NIST Privacy Framework, and a cleaner IT environment.

CMDB relationship mapping for Configuration Items

No configuration item exists in isolation. Servers connect to applications that rely on databases, which may run across multiple cloud environments. A single failure in one component can ripple across the entire service chain, causing outages, disrupting customers, and increasing risk.

CI relationship mapping in your CMDB strengthens risk management, supports software asset management, and aligns with broader enterprise IT governance goals. The key use cases include:

• Service impact analysis. When a CI fails, dependency mapping shows which applications, users, or business services are affected so IT leaders can prioritize what to fix first.
• Root-cause analysis. Tracing issues back to the exact failing component reduces mean time to resolution (MTTR) instead of treating symptoms.
• Prevention of cascading failures. A clear view of how CIs connect lets IT teams plan changes or updates without accidentally breaking downstream services.
• Faster incident response. Visual maps help even non-technical stakeholders grasp the scope of an outage or planned change quickly.

Traditional CMDBs display data in tables and lists. Virima’s ViVID™ service mapping goes further by overlaying ITSM incidents, change records, event management alerts, and NIST NVD vulnerabilities onto dynamic service maps. The NVD integration is included at no additional charge, so vulnerability context sits alongside your CI maps without a separate license.

With ViVID™, IT leaders can see relationships between servers, applications, networks, and cloud services updated through recurring discovery scans, visualize the potential impact of proposed changes before approving them, and pinpoint critical paths during outages to speed up recovery. You are not looking at a static database. You are getting a live, explainable display of your entire IT ecosystem that supports faster, better-informed decisions.

Best practices for managing Configuration Items

A few principles make the biggest difference in keeping your CMDB clean, accurate, and useful:

• Decide what to track. Focus on critical systems and services, not every minor component. A bloated CMDB is as dangerous as an incomplete one.
• Keep CI data consistent. Standardize fields like name, type, owner, and relationships for clarity across teams and tools.
• Follow a CI lifecycle. Add new CIs, update details after changes, and safely retire unused ones to prevent ghost dependencies.
• Automate discovery. Use recurring scheduled scans to keep CI records aligned with discovery-sourced CMDB data instead of relying on manual spreadsheets.
• Map relationships. Visualize dependencies for better impact analysis and faster troubleshooting.
• Assign ownership. Make teams or individuals accountable for keeping CI data accurate. Ownership is not optional when AI agents act on CI records.
• Audit regularly. Review data to maintain compliance and catch configuration drift before it causes problems. Virima’s SOC 2 Type II certified platform supports audit readiness out of the box.
• Integrate with ITSM. Feed accurate CI data into incident, problem, and change management workflows so every process decision runs on trusted runtime truth.

How to manage Configuration Items with Virima

Virima makes managing configuration items straightforward. All your CIs are organized and tracked through the CMDB with automated discovery and integrations.

The first step is getting your CIs into the system:

• Run Virima Discovery scans across your network (agentless, using hundreds of out-of-the-box, extendable probes and sensors)
• Deploy lightweight Discovery Agents for Windows, macOS, and Linux devices
• Integrate with cloud platforms like AWS or Azure
• Import data using CSV templates

Once your CIs are in place, our service mapping automatically connects the dots, showing how assets, applications, and services relate to each other. ViVID™ then overlays incidents, changes, and vulnerability data onto those maps. You can also add any missing links manually to keep the full picture accurate.

If you are already running ServiceNow, Virima syncs CI and configuration management data directly into your ServiceNow CMDB, so you get enriched, discovery-sourced data without replacing your existing ITSM platform. See how our approach compares to alternatives on our Virima vs. Device42 vs. ServiceNow comparison page.

Inside the CMDB, you find all the details about your configuration items along with visual maps that make change planning, impact analysis, and troubleshooting far easier to get right. Learn why organizations choose Virima as their trusted runtime truth layer for CMDB and IT discovery.

Move faster. Act safely.

Schedule a Demo to see how Virima keeps your configuration items organized, mapped, and governance-ready for agentic IT operations.

FAQs

Q1: What is the role of a configuration item in ITIL configuration management?

A configuration item is any component in your IT environment, whether hardware, software, documentation, people, or facilities, that must be tracked to deliver IT services reliably. In ITIL configuration management, CIs maintain a clear view of dependencies, which enables informed decisions for incident resolution, change management, and service continuity. Virima’s ITSM platform holds PinkVERIFY ITIL 4 certification for Service Asset and Configuration Management (SACM), so CI tracking aligns with verified ITIL practices out of the box.

Q2: How can an accurate CMDB improve ITIL configuration management processes?

A well-maintained CMDB stores detailed CI records and their relationships. This visibility leads to faster incident response, accurate impact analysis for changes, and fewer service disruptions. It also gives AI agents the trusted runtime truth they need to take action without introducing unplanned risk to the environment.

Q3: Which types of Configuration Items should be prioritized for tracking?

Start with CIs that directly impact service delivery: key servers, core applications, databases, network devices, business-critical documentation, and relevant personnel roles. Tracking these first ensures operational continuity and supports compliance. As your CMDB matures, you can extend tracking to supporting CIs like middleware, virtual dependencies, and facility records.

Q4: How do Configuration Items support change management and incident resolution?

CIs make dependencies visible. Before making a change, teams can analyze affected CIs to prevent disruptions. During incidents, CI relationships help identify root causes quickly, which reduces downtime and improves overall service reliability. Virima’s change impact analysis shows downstream CI impact before a change is approved, so teams move faster and act safely.

Q5: What tools can help maintain up-to-date configuration item records?

Tools like Virima offer automated discovery with hundreds of out-of-the-box, extendable probes and sensors, recurring scheduled scans that keep CI data current through discovery-sourced CMDB data, and machine-learning-driven relationship mapping. ViVID™ service maps then present live, explainable views of dependencies, infrastructure, and service relationships for smarter ITIL-driven decisions.

Q6: What is the difference between a CI and an IT asset?

A configuration item tracks service delivery and operational impact. An IT asset tracks financial value and lifecycle costs. The key distinction is scope: a CI can be something with no purchase price, like a process document or a virtual service dependency, while an asset is always something the organization owns or licenses. Many items, such as a production server, qualify as both. IT Asset Management and CMDB work best when they share data, so teams see financial and operational context together.

Q7: What are the main CI types in ServiceNow, and how do they map to ITIL types?

ServiceNow organizes CIs into a hierarchical class structure built on a base class called Configuration Item (cmdb_ci). Key subclasses include:

• cmdb_ci_computer – Servers, desktops, and laptops (maps to Hardware CIs in ITIL)
• cmdb_ci_network_gear – Routers, switches, and firewalls (maps to Hardware CIs)
• cmdb_ci_appl – Applications and software packages (maps to Software CIs)
• cmdb_ci_service – Business services and technical services (maps to Service CIs)
• cmdb_ci_database – Database instances and schemas (maps to Software CIs)
• cmdb_ci_storage_device – Storage arrays and SAN devices (maps to Hardware CIs)

When you run Virima alongside ServiceNow, discovery-sourced CI data syncs directly into the correct ServiceNow CMDB class, so your class hierarchy stays accurate without manual population. For a deeper look at how the ServiceNow CMDB workspace is structured, our guide on CMDB workspace in ServiceNow covers the workspace, CI classes, and relationship types in detail.

Q8: How are CIs created and maintained?

CIs enter the CMDB through three main methods. Automated discovery is the most reliable: IT discovery tools run scheduled scans across your network and endpoints, identifying hardware, software, and dependencies and populating CI records with discovery-sourced data automatically. Manual entry works for CIs that discovery cannot reach, such as documentation CIs, people CIs, or external services. Import from CSV or spreadsheet templates lets teams migrate existing asset data into the CMDB in bulk.

Maintenance follows the same three paths. Discovery-sourced CI records update automatically when the next scheduled scan runs and detects a configuration change. Manual CIs require a defined ownership and review process to stay current. Regular CMDB audits, using health scoring to flag stale or unowned records, complete the maintenance picture.

Q9: What is a CI record?

A CI record is the structured database entry in your CMDB that describes a single configuration item. At a minimum, every CI record contains a unique CI ID, CI name, CI type/class, status (active, retired, or in test), owner or owning team, and location. Most CI records also include version or patch level, relationships to other CIs, discovery source and last-discovered date, and the change and incident history linked to the CI.

The discovery source and last-discovered date fields are especially important for agentic IT governance. When an AI agent acts on a CI record, it needs provenance information to verify whether the record is authoritative. A CI record without a discovery source is effectively unverified data, which creates unacceptable risk at machine speed.

Q10: What are some configuration item examples?

Configuration items span every layer of the IT environment. Here are six concrete examples:

1. Production web server (Hardware CI) – A physical or virtual server hosting a customer-facing application. The CI record includes hostname, IP address, OS version, owner, and relationships to the application and database CIs it supports.
2. ERP application (Software CI) – An enterprise resource planning application such as SAP or Oracle. The CI record includes version, vendor, license type, and relationships to the database and server CIs it runs on.
3. Firewall and active ruleset (Hardware/Configuration CI) – A network firewall with its current configuration. The CI record includes device model, firmware version, owner, and relationships to the network segments it governs.
4. Incident response runbook (Documentation CI) – A documented process for responding to a specific class of incident. The CI record includes version number, author, owner, and links to the service CIs the runbook covers.
5. Service owner role (People CI) – The named individual or team responsible for a business service. The CI record includes name, contact details, and relationships to the service CIs they own, supporting ownership attribution for agentic operations.
6. Primary data center (Facility CI) – The physical location hosting production infrastructure. The CI record includes address, power capacity, cooling specifications, and relationships to all hardware CIs co-located there.