Why Your ServiceNow CMDB Is Lying to You

A CMDB nobody trusts is not a data problem. It is a governance problem wearing a data problem's clothes.

This distinction matters because organisations keep trying to solve it with technology. Better discovery tooling. More integrations. A fresh import. What they get is fresh inaccurate data arriving faster than before.

What actually goes wrong

The pattern is consistent across almost every platform we assess:

Discovery runs, but nobody owns reconciliation. ServiceNow's Discovery tool is excellent at finding things. It is not good at deciding what to do when what it finds conflicts with what is already in the CMDB. That decision requires a human with authority, and in most organisations, that human does not exist.

CI lifecycle has no owner. Configuration items are created (often correctly) and then never decommissioned. Servers get retired, the CMDB record stays active. Applications get sunset, their CIs remain. After eighteen months, somewhere between thirty and sixty percent of your CI records are stale.

The data model grew organically. What started as a clean class hierarchy became a negotiation with every team that wanted their things in the CMDB slightly differently. Now you have six different ways to represent a server and no canonical definition of what a "service" actually is.

Nobody checks the quality metrics. Most platforms have ServiceNow's built-in CMDB Health dashboard available. Most administrators have never looked at it. The score is not great. Nobody knows.

Why this matters more now

Every downstream service depends on CMDB accuracy. Incident routing relies on it. Change impact assessment relies on it. Cost allocation reports rely on it. When AI enters the picture, and it is entering the picture, the dependency compounds. An AI that routes incidents based on stale service ownership data makes confidently wrong decisions at scale.

Three things to check this week

You do not need a full remediation engagement to get a read on where you stand. Start here:

Check your CI count trend. Pull a report of CI records created vs decommissioned over the last twelve months. If the gap is growing, you have a lifecycle problem.

Run the CMDB Health dashboard. It is under Configuration → CMDB → Health. Read the completeness and correctness scores. If they are below eighty percent, the platform is lying to everything built on top of it.

Find one business-critical service and trace it. Pick something that matters: payroll processing, customer onboarding, a core IT service. Map every CI that supports it. Ask a human who actually runs that service whether the map is accurate. The answer will tell you what you need to know.

What good looks like

A well-governed CMDB is not a perfect CMDB. Perfect is the wrong goal. What you want is a CMDB with known quality: one where the business-critical CI classes are accurate and governed, the quality metrics are monitored, and the remediation backlog is prioritised and visible.

That state is achievable in most organisations. It requires architectural design, not just tooling. And it requires someone owning it continuously, not just at project kickoff.

If you want an honest read on where your platform sits, we offer a platform assessment that covers CMDB specifically: a short call, then a read-only script your admin runs, and you get a written report, not a sales deck.