A configuration item (CI) is any component, service element, or infrastructure resource that must be managed to ensure the successful delivery of IT services. CIs are tracked individually in a configuration management system, where their attributes, status, and relationships to other CIs are recorded and maintained. Under the ITIL framework, a CI is formally defined as any component that needs to be managed in order to deliver an IT service.
The scope of what qualifies as a configuration item varies depending on your organisation’s size, industry, and management goals. In practice, organisations define CIs based on what they need to control, change, or report on. The sections below unpack the key questions around configuration items, from how they are categorised to what data they hold.
What types of assets count as configuration items? Configuration item examples
A CI is any component that contributes to an IT service and requires management throughout its lifecycle. The most common types fall into five broad categories: hardware, software and applications, network and infrastructure, services and processes, and documentation and contracts. Each type plays a distinct role in how infrastructure is tracked and maintained.
Hardware configuration items
Physical devices are among the most straightforward configuration items. Each piece of hardware is recorded individually so that its location, ownership, status, and relationships to other components can be tracked over time.
- Servers: Physical and rack-mounted servers hosting applications or data
- Laptops and desktop computers: End-user devices connected to the corporate network
- Storage arrays: Dedicated storage hardware including SANs and NAS devices
- UPS units and PDUs: Power infrastructure that supports uptime for critical systems
- Printers and mobile devices: Peripheral hardware managed for connectivity and compliance
- HVAC systems: Facility equipment that directly affects the operational environment of data centres
Software and application configuration items
Software CIs cover everything from core operating systems to licensed business applications. These items are tracked because changes to them can ripple across dependent services and infrastructure.
- Operating systems: Windows Server, Linux distributions, and macOS environments
- Licensed applications: ERP platforms, CRM systems, and productivity suites
- Middleware: Integration layers and message brokers connecting applications
- Databases: SQL and NoSQL instances storing business-critical data
- Cloud services: SaaS platforms, PaaS environments, and IaaS subscriptions
- Containers and virtual machines: Virtualised workloads that host applications or services
Network and infrastructure configuration items
Network CIs define the connectivity fabric of an organisation’s IT environment. Tracking them individually allows teams to model the impact of a network change before it is made.
- Firewalls: Hardware and software firewalls controlling traffic between network segments
- Switches and routers: Core network devices managing data routing and switching
- Load balancers: Devices distributing traffic across servers to ensure availability
- VLANs: Virtual network segments that logically separate traffic
- API integration endpoints: Interfaces connecting internal and external systems
- Wireless access points: Devices providing wireless connectivity across facilities
Service and process configuration items
Entire IT services can be registered as CIs, capturing the combination of hardware, software, and processes that deliver a specific business function. This level of CI enables end-to-end impact analysis across service dependencies.
- IT services: Email, identity management, and ERP services defined in the service catalogue
- Business processes: Documented workflows that depend on specific IT components
- Service level agreements: Formal commitments tied to specific service CIs
- Monitoring configurations: Alert thresholds and dashboards that govern service health
Documentation and contract configuration items
Documentation CIs are often overlooked but are essential for governance, compliance, and knowledge management. Tracking them as CIs ensures they remain current and linked to the components they describe.
- Configuration baselines: Approved snapshots of a CI’s authorised state at a point in time
- Runbooks and operational procedures: Step-by-step guides tied to specific infrastructure components
- Vendor contracts: Agreements governing hardware and software support terms
- Licence records: Documentation of software entitlements and compliance obligations
- Disaster recovery plans: Recovery documentation linked to the CIs they cover
How are configuration items used in a CMDB?
A Configuration Management Database (CMDB) stores all CI records and, crucially, maps the relationships between them. This relational view allows IT teams to understand how components depend on one another, assess the impact of a change or failure, and support processes like incident management, problem management, and change control.
When an incident is raised, the CMDB allows support teams to quickly identify which CIs are affected and which upstream or downstream services might be disrupted. During planned changes, teams query the CMDB to model the potential blast radius before making modifications. This reduces unplanned outages and supports more confident decision-making.
The CMDB also underpins compliance and audit processes. Because every CI has an owner, a status, and a history of changes, organisations can demonstrate control over their infrastructure to auditors and regulators. Without a well-maintained CMDB, this visibility is difficult to achieve at scale.
The four core processes of configuration management
ITIL defines four core processes that govern how CIs are managed within a CMDB. Understanding these processes is essential for IT professionals and ITSM consultants who are responsible for maintaining configuration data.
- CI identification: The process of selecting, classifying, and labelling every component that will be tracked as a CI, including defining its scope, type, and naming conventions.
- Change control: Ensures that no CI is modified without an authorised change record, linking every update back to an approved request and maintaining an auditable trail.
- Status accounting: Tracks the current and historical states of every CI record — from ordered through active to retired — so that the CMDB reflects the real-world state of the environment at any given point in time.
- Configuration audit: Verifies that the actual environment matches the authorised baseline recorded in the CMDB, identifying discrepancies caused by unauthorised changes or configuration drift.
Best practices for keeping CI records accurate
A CMDB is only as valuable as the accuracy of the data it holds. The following practices help organisations maintain CI records that are reliable enough to support real operational decisions.
- Automate CI discovery: Use automated discovery tools to detect changes in your environment in real time. Manual updates alone cannot keep pace with the rate of change in modern infrastructure, and gaps in data quickly undermine trust in the CMDB.
- Assign a named owner to every CI: Each CI record should have a clearly identified owner who is accountable for keeping that record accurate. Ownership without accountability produces stale data.
- Integrate CMDB updates into the change management workflow: No change record should be closed without a corresponding CI record update. Embedding this step into the workflow ensures that the CMDB reflects every approved modification.
- Run regular configuration audits: Schedule periodic audits to reconcile actual CIs discovered in the environment against the authorised CIs recorded in the CMDB. Discrepancies signal either unauthorised changes or data quality issues that need to be resolved.
- Start narrow and expand gradually: Begin with a well-defined, high-priority CI scope — typically critical infrastructure and core services — and broaden coverage incrementally. Trying to capture everything at once produces low-quality data that erodes confidence in the system.
What is the difference between actual and authorized configuration items?
Not every CI in your environment has been formally approved for management. CMDB practice distinguishes between two important categories: actual CIs and authorized CIs.
Actual CIs are items discovered in the live environment, typically through automated discovery tools that scan the network and catalogue what is running. They reflect the real state of the infrastructure at a given moment, regardless of whether those items were formally approved or sanctioned. Authorized CIs, by contrast, are items that have been deliberately approved for management through the change management process. They represent the intended, governed state of the environment — what should be there according to approved records.
When actual and authorized CIs diverge, it signals a problem. A CI present in the environment but absent from the authorized list may indicate an unauthorized change, shadow IT, or a missed update to the CMDB. Organisations reconcile the two sets regularly as part of the configuration audit process, using the gap between discovered and authorized CIs as an early warning system for configuration drift and governance failures. ITIL draws a clear boundary between the discovered state and the authorized baseline, treating reconciliation as a core discipline of configuration management.
What’s the difference between a configuration item and an asset?
An asset is anything that has financial value to an organisation, while a CI is anything that needs to be managed because it supports an IT service. The two concepts overlap significantly but are not identical. A laptop is both an asset (it has purchase value) and a configuration item (it runs services and connects to the network). A software licence may be an asset but not necessarily a CI if it is not actively managed within the service infrastructure.
The key distinction lies in purpose. Asset management focuses on financial tracking, procurement, depreciation, and disposal. Configuration management focuses on operational relationships, service dependencies, and change impact. ITIL draws a clear boundary between asset management and configuration management as complementary but distinct disciplines — many organisations run both processes in parallel, with the CMDB and asset register sharing data but serving different stakeholders and decisions.
In practical terms, not every asset becomes a CI. A piece of furniture in the office has financial value and may appear in an asset register, but it does not support IT services and would not typically be tracked in a CMDB. Conversely, some CIs — such as virtual network segments or documentation files — may have no direct financial value but are critical to service management.
How do you decide what to include as a configuration item?
The decision comes down to whether managing the item improves your ability to deliver, change, or restore services. A useful test is to ask: if this item failed or changed unexpectedly, would it affect a service or make an incident harder to resolve? If yes, it belongs in your CMDB as a CI.
Organisations commonly use three criteria to guide inclusion decisions:
- Service impact: Does the item directly support a business or IT service?
- Change frequency: Is the item subject to changes that could affect other components?
- Relationship value: Does knowing its connections to other items improve decision-making?
Starting with a narrow, well-maintained scope is almost always more effective than attempting to capture everything at once. Over-populating a CMDB with low-value CIs creates noise that undermines trust in the data. A phased approach, beginning with critical infrastructure and expanding gradually, produces more reliable and actionable records.
How granular should a configuration item be?
CIs can range from a complete IT service down to a single hardware component or individual program module. The right level of granularity depends on how much control and visibility your organisation needs — finer granularity gives more precision but also creates more records to maintain. A useful principle is to register CIs at the level where independent management adds real value.
The concept of a top-level CI helps structure this thinking. A top-level CI is the highest-level item in a hierarchy, with child CIs nested beneath it. For example, a web application server might be the top-level CI, with the following child CIs beneath it:
- Operating system
- Application software
- Database instance
- Network interface card
As a practical rule of thumb, the lowest-level CI should be the smallest unit that can be independently changed, failed, or replaced. If two components always change together and are never managed separately, they are likely better represented as a single CI rather than two.
What attributes does a configuration item record contain?
A CI record contains the structured data needed to identify, manage, and relate that item to others. Core attributes typically include a unique identifier, a name or description, the item type or category, its current status (active, retired, in maintenance), the owner or responsible team, and the date it was added or last modified.
Beyond these basics, most organisations add attributes specific to the item type. A server record might include its operating system version, physical location, IP address, and hardware specifications. A software application record might include its version number, licence details, and the business process it supports. A service record might list its agreed availability targets and the CIs it depends on.
Relationship attributes are equally important. Each CI record should document how it connects to other items, whether as a dependency, a component, a parent, or a child. These relationships are what transform a list of records into a genuine map of your infrastructure, enabling the impact analysis and change planning that make a CMDB genuinely useful.
Version control and release management for configuration items
Each CI record should carry a version number that is incremented whenever a significant change is made to the item. For example, when a server OS is patched, the CI record version increments from v2.1 to v2.2, and the change record reference is logged against the new version — creating a clear, auditable history of every modification.
A release is a set of authorised changes deployed together, and a single release may affect multiple CIs simultaneously. When a release is deployed, every affected CI’s record should be updated with the new version number and a reference to the release that triggered the change. This links CI versioning directly to the change management workflow and ensures that the CMDB reflects not just what changed, but why and when.
Modern CMDB implementations support this by linking CI versions to code repositories, artifact repositories, or a Definitive Media Library (DML) for software CIs. The DML acts as the authoritative source for approved software versions, ensuring that only sanctioned releases are deployed and recorded against CI records.
What is the lifecycle of a configuration item?
Every CI passes through a defined set of stages from the moment it is first identified to the point at which it is decommissioned. Tracking these stages through CI lifecycle management ensures that the CMDB always reflects the current state of each item and provides a historical record of how it has evolved over time.
Planning and design
The CI lifecycle begins before the item is procured or built. During planning and design, the CI is identified as a future component, its attributes are defined, and its place within the service architecture is established. The CMDB record is created at this stage with a status of planned, allowing teams to model dependencies and assess the impact of the new item before it exists in the environment.
Procurement and registration
Once a CI is ordered or commissioned, its record is updated to reflect a status of ordered or procured. Key attributes such as vendor details, expected delivery date, and assigned owner are recorded at this point. Registering the CI early ensures it enters the change management workflow from the outset rather than being discovered and retrospectively added after deployment.
Testing and staging
Before a CI enters the production environment, it passes through a testing or staging phase. The CI record status is updated to in test, and any configuration changes made during this phase are logged against the record. This stage is critical for software CIs in particular, where version numbers and configuration baselines must be confirmed before the item is approved for deployment.
Deployment to production
When a CI is approved and deployed, its record status changes to active. The deployment is linked to the authorising change record, and the CI’s relationships to dependent services and other CIs are confirmed and recorded. From this point, the CI is part of the authorised configuration baseline and is subject to formal change control for any future modifications.
Active management and change
During its operational life, a CI may be modified, upgraded, or reconfigured multiple times. Each change is governed by the change management process, and the CI record is updated accordingly — including version increments, updated attribute values, and references to the change records that authorised each modification. Status accounting tracks the full history of these changes, providing an auditable trail of the CI’s evolution.
Retirement or disposal
When a CI reaches the end of its useful life, it is formally retired. The CI record status is updated to retired or disposed, and the date and method of disposal are recorded. Retiring a CI in the CMDB — rather than simply deleting the record — preserves the historical data and ensures that dependent services are updated to reflect the change. This final stage closes the CI lifecycle and supports accurate reporting on infrastructure turnover and asset disposal.
Managing complex configurations beyond IT: how iONE360 applies the same principles
The same principles that make CMDB-based CI management effective — structured data, clear relationships, and controlled change — apply equally to managing configurable physical products. For manufacturers and retailers of customisable furniture and home furnishings, the challenge is strikingly familiar: how do you manage thousands of product variants, interdependent business rules, and consistent visual outputs without losing control or consistency?
That is exactly the challenge we built iONE360 to solve. Our 3D product configurator is purpose-built for the furniture and home furnishings industry, handling the full complexity of configurable products — from fabric and finish combinations to structural variants and pricing logic — with the same rigour that a well-maintained CMDB brings to IT configuration management. Here is what we make possible:
- Unlimited configuration options managed within a single platform, including complex business rules and pricing structures
- ERP-aligned logic so that product configurations speak the same language as your existing enterprise systems
- Automated high-quality visuals generated for every configuration without manual effort per variant
- Seamless integration with PIM, ERP, CMS, and webshop environments
- Guided selling experiences that lead customers through even the most complex product choices step by step
The result is fewer errors, higher conversion rates, reduced returns, and consistent brand presentation across every sales channel. If you are ready to bring your configurable product range under control and present it with confidence, explore what iONE360 can do for your business.