Almost every CMDB is accurate on the day it goes live. A meaningful share are distrusted within two quarters, and once trust goes, it does not come back easily — people build their own spreadsheets, and the CMDB becomes a system that is maintained but not used.
The decay is predictable, and it usually traces to four decisions taken at design time.
Scope by question, not by asset
The common failure is deciding to model everything discoverable. It produces a CMDB with enormous surface area, most of which nobody queries, all of which has to be maintained.
Work backwards from the questions the business actually asks instead. Typically these are few:
- If this component fails, which business services degrade?
- Which customers or users are affected by this incident?
- What will this change touch, and what is the blast radius?
- What is running on infrastructure we are about to retire?
- Where is this application's data, and who can reach it?
Model what those questions require and stop. A smaller CMDB that is trusted is worth considerably more than a complete one that is not, and you can always extend scope later — extending is easy, rebuilding trust is not.
Automate population, without exception
Anything populated by humans remembering to update it will decay. This is not a discipline problem to be solved with governance; it is a structural property of manual data entry with no immediate feedback loop.
Every CI class needs an automated source:
- Infrastructure — discovery, run on a cadence with credential coverage monitored
- Cloud resources — provider APIs, with tagging enforced by policy rather than convention
- Applications and dependencies — service mapping from observed traffic, not interviews
- Business services — the one place manual definition is legitimate, because it is a business decision, and it changes slowly
Where you genuinely cannot automate a class, that is a strong signal to ask whether it belongs in the CMDB at all.
Certify continuously, with named owners
Automated population gets you accurate infrastructure data. It does not get you accurate ownership, criticality or support group assignment, and those are usually the fields people most need to be right.
Certification campaigns sample CIs and ask a named owner to confirm the attributes discovery cannot determine. Run them continuously on a rolling sample rather than annually — an annual campaign is an event people learn to click through, a rolling one is a habit.
Make decay visible before it becomes distrust
The reason CMDB decay is so damaging is that it is invisible until someone relies on the data during an incident and finds it wrong. By then the damage is to credibility, not just to a record.
A health dashboard should surface, at minimum:
- Discovery coverage — what proportion of known infrastructure is being scanned successfully
- Staleness — CIs not updated within their expected cycle
- Orphans — CIs with no relationships, which usually means the model is wrong
- Required-field completeness by class
- Certification pass rate and overdue campaigns
Review it monthly with the same seriousness as an SLA report. A CMDB whose health is reported and acted on stays usable; one whose health is nobody's specific job does not.
The test
There is a simple way to know whether yours is working. During the next significant incident, does anyone open the CMDB to determine impact?
If the answer is that people ring a colleague who knows the environment instead, the CMDB is not the system of record regardless of what the governance document says. That is worth knowing before the next audit rather than during it.