Home / Glossary / CMDB (Configuration Management Database)
Tech & ITCMDB (Configuration Management Database)
By Sitraka Forler · Lecturer, Durham Business SchoolUpdated 3 October 2026 About this site
An inventory of every IT component and of what depends on what.
Each server, database, application or service is a configuration item, and the CMDB also stores the relationships between them, so it answers "if this fails, what breaks?" during an incident or before a change is approved. ServiceNow and BMC Helix CMDB are common tools, usually fed by automated discovery. It is more than an asset list, and a stale CMDB is worse than none because people trust it.
The intuition
It is two in the morning and a database has stopped answering. An asset spreadsheet tells you the machine exists, who bought it and when its warranty ends, and none of that answers the question you need in the next sixty seconds: which customers just lost something, and who should you wake up. A configuration management database answers it, because it stores the components and what depends on what. Each thing it tracks is a configuration item, or CI: a server, a virtual machine, a database instance, an application, a network switch, even a business service such as Client Portal. The ITIL 4 practice guide for service configuration management defines the CMDB as "a database used to store configuration records throughout their lifecycle", and adds that it also maintains the relationships between those configuration records. That second sentence carries the value. The relationships turn a parts list into a map you can walk.
The record for one CI holds attributes: a unique identifier, a class such as Linux Server or Business Service, a name, an owner, an environment, a lifecycle state. On its own that is still an inventory. Relationships are stored as separate rows, and each row is a typed, directed link between two CIs: Portal Web runs on web-prd-01, Billing API uses billingdb-prd, web-prd-01 is virtualised by esx-prd-07. Every type carries a name in each direction: the Billing API edge reads "uses" downwards and "used by" upwards, and a hosting edge reads "runs on" downwards and "hosts" upwards. Walking upwards from a failed CI is exactly how impact analysis works. Filling all this in by hand does not scale, so discovery tools scan the estate over SSH, WMI or SNMP and report what they find. A reconciliation engine then decides whether each incoming record is a CI you already hold, using identification rules such as serial number first and name plus IP address second, and which data source may overwrite which attribute.
Two things go wrong at the edges. Scope: a CMDB that tries to hold every monitor and mouse becomes a second asset register nobody trusts, so teams limit it to CIs whose failure changes a service, and keep the financial detail in asset management. Decay: cloud instances appear and vanish between scans, containers live for minutes, decommissioned kit is never retired, and an expired discovery credential can silently stop a whole subnet being scanned. A stale CMDB is more dangerous than no CMDB, because people act on it at two in the morning without checking. Practitioners therefore run it as a product with a named owner: automate discovery instead of asking humans to type, audit a sample of CIs against reality on a schedule, and report completeness and correctness rather than row count. What you buy with that effort is impact analysis during an incident, a blast radius before a change is approved, and an honest answer to "what is this server for?".
Example
# What each configuration item runs on, as a CMDB records it
runs_on = {"Trading App": "App Server 1", "App Server 1": "VM Host HV-01"}
item = "Trading App"
while item in runs_on: # follow the chain down to the bottom layer
print(f"{item} runs on {runs_on[item]}")
item = runs_on[item]
# Trading App runs on App Server 1
# App Server 1 runs on VM Host HV-01Walk a seven-CI map upwards to find the blast radius of three different failures
- Write down the configuration items. Seven CIs, each one row with a class and a name: Client Portal (business service), Portal Web and Billing API (applications), web-prd-01 and app-prd-02 (Linux servers, both virtual machines), billingdb-prd (database instance) and esx-prd-07 (VM host).
- Add the relationships, each a typed directed row of the form "CI depends on CI". Client Portal depends on Portal Web; Client Portal depends on Billing API; Portal Web runs on web-prd-01; Billing API runs on app-prd-02; Billing API uses billingdb-prd; billingdb-prd runs on app-prd-02; web-prd-01 is virtualised by esx-prd-07; app-prd-02 is virtualised by esx-prd-07. That is 8 relationship rows against 7 CIs, so 8 - 7 = 1 more edge than node in an estate this small.
- Fix the direction of travel. Impact analysis walks upwards, following each edge from the failed CI to whatever is "used by" it, then repeating from every CI you reach until nothing new appears.
- Failure 1, billingdb-prd goes down. Used by: Billing API. Billing API is used by: Client Portal. Nothing above that, so the affected set is {Billing API, Client Portal}, a blast radius of 2 CIs, of which 1 is a business service. Portal Web still runs, so Client Portal is degraded rather than dead.
- Failure 2, app-prd-02 fails. Used by: Billing API and billingdb-prd, which is 2 CIs at the first hop. From billingdb-prd you reach Billing API again, which you must count once, not twice. From Billing API you reach Client Portal. The affected set is {Billing API, billingdb-prd, Client Portal}, a blast radius of 3.
- Failure 3, the VM host esx-prd-07 fails. Used by: web-prd-01 and app-prd-02. From web-prd-01 you reach Portal Web, then Client Portal. From app-prd-02 you reach Billing API and billingdb-prd, and Client Portal again, already counted. The affected set is {web-prd-01, app-prd-02, Portal Web, Billing API, billingdb-prd, Client Portal}, a blast radius of 6, which is 7 - 1 = 6, every CI in the map except the host itself. Both applications are gone, so Client Portal is fully down.
- Compare the three numbers: 6 / 2 = 3, so the host's failure touches three times as much as the database's, and 6 / 3 = 2, twice as much as the server's. The map also exposes a design fault nobody wrote down anywhere: two servers that look like redundancy both sit on one host, so the pair fails together.
- Now do it badly, on purpose. Count only the direct neighbours of esx-prd-07 and you report 2 affected CIs instead of 6, understating the change by 6 - 2 = 4 CIs and, worse, missing the business service entirely, because Client Portal sits three hops up rather than one.
The CI records tell you what exists, but only the typed relationships, walked upwards to the top and de-duplicated on the way, tell you what breaks when one thing fails.
Common pitfalls
- Treating the CMDB as an asset register. Asset management answers who owns a thing, what it cost, when its licence or warranty expires and when to depreciate it; the CMDB answers what it is connected to and what fails with it. The same laptop can appear in both, and a business service that nobody ever bought belongs only in the CMDB.
- Creating CIs without relationships. A CMDB full of servers and no edges answers every impact query with "nothing depends on this", which reads like a green light and approves a change that takes a service down. The relationships are the deliverable, not the CI count.
- Reporting only the first hop. An impact query that stops at the direct neighbours of a failed CI misses the business service sitting three hops up, which is the one the incident manager has to name. Walk the graph to the top, and count each CI once even when several paths reach it.
- Trusting a CI record without looking at when it was last seen. Check the last discovered timestamp and the lifecycle state before you act on a record: a CI that discovery has not touched for weeks may be decommissioned, or may sit behind a credential that expired and quietly stopped a whole subnet being scanned.
- Letting scope grow until the CMDB is unmaintainable. Every extra CI class and attribute is something that must be discovered, reconciled and audited forever, so decide first which questions the CMDB has to answer, then model only what those questions need.
Frequently asked questions
What is a CMDB?
A CMDB, or configuration management database, is the store of the IT components an organisation runs and of the relationships between them. The ITIL 4 practice guide for service configuration management defines it as a database holding configuration records throughout their lifecycle, and says it maintains the relationships between those records as well. Each component is a configuration item, or CI, and it is the relationships that let an incident responder trace a failure up to the services and customers it takes with it, and let a change reviewer see what a proposed change would touch before approving it.
What is a configuration item (CI) in a CMDB?
A configuration item is anything the CMDB tracks as a single record: a physical server, a virtual machine, a database instance, an application, a network device, or something with no hardware at all such as a business service. ITIL 4 puts it broadly, as any component that has to be managed in order to deliver an IT service. Each CI has a class, a unique identifier, an owner, an environment and a lifecycle state. CIs on their own are an inventory; the typed relationships between them are what make the database useful.
What is the difference between a CMDB and IT asset management?
IT asset management follows the commercial lifecycle of a thing you paid for: purchase, cost, contract, licence, warranty, depreciation and disposal. A CMDB follows the operational configuration: what a component is, how it is configured and what depends on it. A server appears in both, a monitor usually only in asset management, and a business service only in the CMDB. ITIL 4 draws the same line structurally, splitting the older service asset and configuration management process into two separate practices, IT asset management and service configuration management.
How is a CMDB populated?
Mostly by automated discovery. Agentless scanners reach machines over SSH, WMI or SNMP, or agents report from the host, and cloud and virtualisation platforms are read through their own APIs. Each incoming record then passes through a reconciliation step, called an identification and reconciliation engine in the major tools, which uses identification rules such as serial number first, then name and IP address, to decide whether it is a CI you already hold or a new one, and precedence rules to decide which data source may overwrite which attribute. Manual entry is reserved for what no scanner can see, typically business services and ownership.
Why do CMDBs go stale?
Because reality changes faster than the CMDB is updated. Cloud instances are created and destroyed between scheduled scans, containers live for minutes, decommissioned kit is never retired, expired discovery credentials stop a subnet being scanned without anyone noticing, and relationships that only a human can draw are never drawn. Staleness is dangerous rather than merely untidy, because people trust the CMDB at the worst possible moment.
What is a CMDB used for?
Three jobs mainly. Impact analysis during an incident: walk upwards from the failing CI to see which services and customers are affected, and who owns them. Change management: work out the blast radius of a proposed change before it is approved, and spot single points of failure such as two supposedly redundant servers on one host. And basic accountability: knowing what each component is for, which environment it belongs to and who to call about it.