ServiceNow CMDB Health Check

What a Health Check Engagement for CMDB Covers

A CMDB health check engagement with Oblytech assesses the current state of your configuration database and provides recommendations for improvement. We audit your CI population: how many configurations are you tracking, of what types and how current are they. We assess data quality: what percentage of CIs have complete information, what percentage have stale data, and where are the biggest gaps. We evaluate governance: how are CIs created, how are they kept current and what processes ensure data quality. We interview teams who depend on CMDB data to understand what works and what frustrates them.

Based on assessment, we provide a roadmap for CMDB improvement prioritised by business impact. Quick wins that can be addressed immediately are identified. Structural improvements that require planning are scoped. Governance changes that will prevent future decay are designed. The health check length depends on scope and results in an actionable roadmap.

Typical Starting Problems and Data Quality Issues

Many organisations have CMDBs with significant data quality problems. Some CIs are stale: they were created years ago and never updated, so they no longer reflect reality. Other CIs are missing relationships: a server exists in the database but has no links to the business service it supports or the team that owns it. Some types of CIs are well-populated; others are sparse. Networks and servers might be well-documented while applications and their dependencies are missing.

Configuration count is important to understand scope. If you have several thousand CIs and assess quality is low, you might have hundreds of CIs with data quality issues. If quality assessment shows many CIs missing required fields, the effort to remediate is significant. These numbers help prioritise improvement efforts and estimate effort to reach target quality.

Common data problems include duplicate CIs: the same server appears multiple times under slightly different names. Missing CIs: servers running in production that are not yet in the CMDB. Inaccurate data: IP addresses that are wrong, locations that are outdated, or owning team that is stale. These problems are often discovered when teams need CMDB data for incident response or capacity planning and find the data is not trustworthy.

Assessment and Audit Process

We analyse your CMDB database to understand population and structure. We count CIs by type and assess completeness of key fields. We identify orphaned CIs that have no relationships to services or infrastructure. We compare CMDB to your monitoring and discovery systems to find gaps: monitoring knows of servers that are not in the CMDB, or CMDB has servers that are no longer running. We interview key users to understand what CMDB data they rely on and whether that data is trustworthy.

We also assess your discovery integration if you have one. If you use discovery tools to sync infrastructure, we evaluate whether discovery is working effectively and data is flowing correctly. We check whether discovery data is being enriched with business context in the CMDB or if it remains incomplete.

Data Quality Scoring and Gap Analysis

We score data quality across dimensions: completeness of required fields, accuracy of data checked against real systems, currency of data (how recently was it updated), and uniqueness (are there duplicates). We produce a quality scorecard showing strong areas and weak areas. We identify CIs that are critical for business continuity and ensure quality is highest for those. We identify data sources: which teams create and maintain which data, and where gaps exist.

We analyse gaps and categorise them by effort to remediate. Some gaps can be fixed quickly: assigning an owner to a CI, linking a CI to a service. Others require significant effort: discovering missing CIs, documenting undocumented infrastructure. We prioritise gaps by business impact so quick-win improvements deliver value while longer-term work is planned.

Governance and Process Recommendations

We assess your current CMDB governance: is there a CMDB owner responsible for data quality? Are there procedures for adding new CIs, updating existing ones and retiring old ones? Do teams know they should update the CMDB when infrastructure changes? Are there controls to prevent duplicate CIs or invalid data? Often governance is informal or absent, which is why quality decays.

We recommend governance improvements. Designate a CMDB owner responsible for data quality and continuous improvement. Create procedures for CI lifecycle: creation through retirement. Define data standards so all CIs have required fields. Implement reconciliation processes to detect and correct discrepancies. Establish gatekeeping: infrastructure cannot be deployed without a corresponding CI being created. This governance prevents future data quality problems.

Roadmap and Implementation Priorities

The health check report includes a roadmap organised by time horizons: quick wins that can be achieved soon, medium-term improvements that take longer, and strategic improvements that take longer still. Quick wins build momentum and show value quickly. Medium-term improvements address structural issues like duplicate removal or relationship mapping. Strategic improvements include governance transformation and sustained data quality culture change.

Reading a CMDB you did not build

Many health checks start on the day a new CMDB administrator inherits a database that the previous owner has left half-explained. The request is usually urgent: an audit is approaching, a major incident exposed a wrong service map, or a steering group wants to know whether the configuration data can support a change program. The first job is not to score the whole database. It is to find out which records the platform relies on, which ones it merely stores, and which ones quietly contradict each other.

This section is for the CMDB administrator, the service owner or the operations lead who has to decide what a check should examine before anyone spends time on remediation. It assumes the database is populated and that discovery or an integration has been feeding it for some time.

The checks that reveal the most, and what a failure looks like

Check	What you examine	What a failure usually means
Last-seen age for discovered items	Whether discovery has touched each item recently	Decommissioned hardware still counted as live, or a scan scope that has quietly narrowed
Relationship integrity	Whether dependencies point to active items	Impact views that look complete but route through retired servers
Duplicate candidates	Records sharing a serial, name or address	Two sources creating the same item under different keys
Mandatory field completeness on critical classes	Owner, environment and support group on business-facing items	Incidents routed to a team that no longer exists
Source-of-truth conflicts	Attributes changed by more than one source	No reconciliation rule, so the last writer wins

Each row answers a different question for a different reader. Last-seen age matters most to the discovery owner. Relationship integrity matters most to incident and change teams. A health check that reports one blended score hides which reader is affected, so present the results by consumer.

Sampling instead of scanning everything

Running every check against every record is slow and produces a report too large to act on. A better approach is to start with the classes that business services depend on, then sample the rest. Take a set of services that matter most to the organization, trace each one down to its hosts, applications and databases, and check whether the chain is complete and current. The walk will expose more real defects than any aggregate figure, and it gives you a story that a steering group can follow.

Ordered procedure for the first pass

1. Confirm which processes read the CMDB today, and which of them failed or were slowed by data problems in the past year.
2. Pick a short list of business services from the highest-impact processes and export their configuration chains.
3. Walk each chain and mark every item as current, stale, orphaned or contradicted by another source.
4. Run the duplicate and last-seen checks across the classes those chains use, and record the counts by owner.
5. Check the reconciliation log for the same items to see which source wrote the value last and whether a rule governed the write.
6. Write findings as a short list tied to the processes they affect, and send each owner only the items they can fix.

Knowing when a full health check is the wrong tool

A full health check is not always the right response to unease about configuration data. If one process is failing, a targeted review of that process’s chain is faster and produces a clearer fix. Where nobody owns the classes in question, the check will produce findings that nobody can act on, and the priority should be assigning ownership first. A third case is a database that is being replaced. Auditing records that are about to be migrated or retired wastes effort that a clean import would have made unnecessary.

Frequently asked questions about CMDB health checks

How do we tell a stale item from one that is simply quiet?

A quiet item is still in use and has no reason to change. A stale item has stopped being seen by the source that should maintain it. Compare the last-seen date with the discovery scope for that location. If the item sits outside any active scope, treat it as a scope problem before treating it as a data problem.

Should a health check include the audit evidence for compliance?

It should show what evidence exists and where the gaps are. Producing the audit pack itself is a separate task that depends on the framework being tested. Keep the health check focused on whether the data is accurate enough for the controls to rely on.

Who should receive the findings?

The owner of each affected class receives the items they can correct. The service owner receives the impact summary for the processes that failed. The steering group receives a short statement of which services are at risk from data quality. Sending one long report to everyone guarantees nobody reads the part that concerns them.

What do we do with items we cannot classify?

Park them in a visible list with an owner who must decide within a set review cycle. Do not delete them in the health check. Deletion is a remediation decision, and an item that looks orphaned may be the only record of a dependency that discovery cannot see.

The discovery library guide explains how scan scope affects last-seen dates, and the article on CMDB data quality rules sets out the rules that the checks above should be measured against. If the findings point to a larger repair, the CMDB health remediation service page is the route for that work.

CMDB health check: what it measures and how to read the result

A CMDB health check measures whether configuration records are complete, correct and current enough for the processes that read them. The deciding test is not the overall score but whether the records behind your most important business services pass, because incident, change and impact decisions read those chains first.

In most instances the built-in CMDB Health dashboard is where teams start. It scores three things: completeness, which asks whether the required and recommended fields are filled; correctness, which looks for duplicates, orphans and stale records; and compliance, which compares records with the audit rules your organisation has set. It is a fair screening tool for the classes it has been configured to watch.

Its limits explain why a dashboard is not an assessment. It measures only the classes and fields someone switched on, it cannot say whether the right classes are in the CMDB at all, and a field filled with a wrong value still counts as complete. A health check adds the questions the dashboard cannot ask: which processes depend on which classes, which source owns each attribute, and whether the service maps match how the business describes its services.

Read the result in this order. Start with the defects that touched real incidents or changes in the past year, then the ownership gaps, then the scores. When scores and incident history disagree, trust the history. The numbers worth putting on a recurring review are in the CMDB KPIs and metrics that matter, and the rules that keep fixes in place sit in the CMDB data quality and governance approach.

How is a CMDB health check different from a CMDB audit?

A health check asks whether the data is fit for the processes using it and what to fix first. An audit asks whether the data and its controls meet a stated requirement, and ends in a pass or fail against that requirement. Many teams run a health check first so the audit does not surface known defects.

How often should CMDB health be checked?

Review the dashboard scores for critical classes on a regular schedule, and again after any large discovery or integration change. Run a full assessment when ownership, tooling or the service model changes. A check run once and filed away decays as fast as the data did.

What should be ready before a CMDB assessment starts?

Have the list of services that matter most, read access to the CMDB and reconciliation logs, the names of the teams that own each class, and recent incidents where configuration data was wrong. With those in hand, CMDB consulting can begin with the chains that count.