IT configuration management is one of the most misunderstood practices in ITSM — teams either skip it entirely or build a CMDB that nobody trusts. This guide explains what configuration management actually involves, why it matters beyond just storing asset data, and how to set up a process that supports incident resolution, change decisions, and compliance without becoming a maintenance burden.
What Configuration Management Really Means in ITIL v4
Most people hear "configuration management" and think of a database full of hardware records. That is only part of the picture. In ITIL v4, configuration management is a practice focused on ensuring that accurate and reliable information about configuration items — and the relationships between them — is available when and where it is needed.
A configuration item, or CI, is any component that needs to be managed to deliver a service. That includes:
- Physical assets such as servers, laptops, switches, and printers
- Software including operating systems, applications, and licenses
- Virtual and cloud resources such as VMs, containers, and cloud instances
- Services, service components, and documentation
- People and teams, in some mature implementations
The configuration management database, or CMDB, is the system that stores these records and — critically — the relationships between them. A server CI should be linked to the services it supports, the incidents raised against it, the changes applied to it, and the contracts covering it. That relationship data is what makes a CMDB genuinely useful rather than just an expensive spreadsheet.
Why Most CMDBs Fail and What to Do Instead
The most common reason CMDBs fail is that they are treated as a one-time project rather than an ongoing practice. A team spends weeks importing data, declares victory, and then watches the records go stale within months as devices are added, retired, or changed without anyone updating the database.
Other common failure patterns include:
- Trying to capture everything at once rather than starting with what matters most
- No clear ownership — nobody is accountable for keeping records accurate
- Manual data entry as the primary population method, which does not scale
- Disconnecting the CMDB from the processes that depend on it, such as incident and change management
- No regular audits to catch drift between what the CMDB says and what is actually in the environment
The fix is to treat configuration management as a living practice with defined roles, automated discovery feeding the database, and clear rules about what gets recorded and why.
Start with scope, not completeness
A useful CMDB on day one beats a perfect CMDB that never launches. Define the scope of what you will manage first. A practical starting point is the set of CIs that support your top five or ten business-critical services. Once those records are accurate and trusted, expand outward.
Assign a configuration manager
Someone needs to own this practice. The configuration manager is responsible for defining CI classes and attributes, maintaining the data model, running reconciliation processes, and working with other practice owners to ensure CI data is updated as part of normal workflows.
Designing Your CI Data Model
Before you import a single record, spend time on the data model. The data model defines what types of CIs you will track, what attributes each type carries, and how CIs relate to one another.
A minimal but useful model typically covers:
- Hardware CIs — with attributes like make, model, serial number, location, owner, and lifecycle status
- Software CIs — with attributes like version, vendor, license type, and installation count
- Service CIs — representing the IT services you deliver, linked to the components that support them
- Network CIs — switches, routers, firewalls, and their connectivity relationships
Relationships are as important as the records themselves. Common relationship types include:
- Runs on — software runs on a hardware CI
- Hosted by — a virtual machine is hosted by a physical server
- Depends on — a service depends on a database CI
- Connected to — network topology relationships
- Managed by — links a CI to the team or person responsible for it
Keep the data model as simple as it can be while still answering the questions your teams ask during incidents and changes. Complexity that nobody uses is just maintenance overhead.
Populating the CMDB: Discovery vs Manual Entry
Manual data entry is unavoidable for some CI types, but it should never be the primary method for infrastructure CIs. Networks change too fast and environments are too large for humans to keep up. Automated discovery is essential.
Discovery tools scan the network, identify connected devices, read installed software and configurations, and push that data into the CMDB. When discovery runs continuously or on a regular schedule, the CMDB stays current without relying on people to remember to update records.
Key principles for discovery-driven population:
- Run discovery on a schedule that matches how quickly your environment changes — daily is a reasonable starting point for most organisations
- Set up reconciliation rules so that discovered data updates existing records rather than creating duplicates
- Define authoritative sources for each attribute — discovery may own the IP address field while procurement owns the purchase date field
- Flag CIs found by discovery that have no matching record as candidates for review, not automatic imports
Odysseus, the endpoint asset discovery tool built by IT DEV TECH, is designed specifically to feed accurate, up-to-date CI data into the TIKTING CMDB. It scans endpoints across the network, collects hardware and software inventory, and syncs records automatically so that the CMDB reflects the real environment without manual effort.
Handling cloud and virtual assets
Cloud and virtual resources present a specific challenge because they can be created and destroyed in minutes. Discovery needs to cover cloud APIs and hypervisor management layers, not just the physical network. Include cloud instances, virtual machines, and containers in your CI scope if your organisation runs workloads in those environments.
Connecting Configuration Management to Other ITSM Practices
A CMDB that sits in isolation provides little value. The real return on investment comes when CI data is surfaced at the right moment in other ITSM practices.
In incident management, linking an incident to the affected CI lets you see the CI's history, related open incidents, recent changes, and downstream service dependencies — all of which speed up diagnosis and resolution.
In change management, a change request linked to a CI allows the change advisory board to assess impact by following the relationship map. If a change touches a database CI that three critical services depend on, that dependency is visible before the change is approved rather than discovered during a failed deployment.
In problem management, grouping incidents by CI helps identify which components are generating the most failures and guides root cause analysis.
In service level management, CI-to-service relationships allow SLA reporting to be tied to the components supporting each service, not just to tickets in isolation.
The TIKTING service management platform links incidents, changes, problems, and service requests directly to CI records in the CMDB, so teams working any of those practices have immediate context without switching tools.
Configuration Management Audit and Governance
Even with automated discovery, the CMDB will drift over time. Assets get moved, repurposed, or retired without proper process. Software gets installed outside of approved channels. Cloud resources get provisioned and forgotten. Regular audits are the mechanism that catches this drift before it causes problems.
A practical configuration audit process includes:
- Scheduled reconciliation runs that compare discovery data against CMDB records and flag discrepancies
- Periodic physical audits for hardware CIs in data centres and office locations
- Lifecycle reviews that identify CIs with a status of active but no recent activity or discovery match
- Spot checks triggered by major incidents or failed changes where CI data may have contributed to the problem
For governance, define and enforce a change process that requires CI updates as part of any change closure. A change that deploys a new server should not be marked complete until the server CI is in the CMDB with accurate attributes. Building CI hygiene into change and onboarding workflows prevents the backlog from building up in the first place.
Shadow IT is a related challenge. Devices and software that enter the environment without going through procurement or IT approval will not have CI records unless discovery catches them. Treating unrecognised CIs found by discovery as a governance signal — not just a data quality problem — helps surface shadow IT systematically.
Key Takeaways
- Configuration management is a practice, not a project. It requires ongoing ownership, process integration, and regular audits to stay useful.
- Start with the CIs that support your most critical services and expand scope gradually rather than trying to capture everything at once.
- Automated discovery is essential for keeping infrastructure CI data current. Manual entry alone does not scale.
- The data model matters as much as the data. Relationship mapping between CIs is what enables impact assessment during incidents and changes.
- Connect CMDB data to incident, change, and problem management so teams get CI context at the moment they need it.
- Regular reconciliation and audit processes catch drift and prevent the CMDB from becoming a source of misinformation.
Odysseus provides continuous endpoint discovery that feeds accurate CI data into TIKTING automatically, reducing the manual effort required to maintain CMDB hygiene. If you are evaluating how to bring configuration management to life in your organisation, exploring the TIKTING platform and Odysseus together is a practical starting point.
