How to Measure Data Quality in ServiceNow

“The CMDB is 92 percent healthy” sounds precise, but it can be dangerously incomplete. A percentage only has meaning when teams understand what was measured, which records were included, how thresholds were configured, and whether the result reflects the decisions people actually make with the data. A high completeness score does not prove that values are correct. A low duplicate rate does not prove that relationships are useful. A dashboard can summarize evidence, but the organization still has to decide what quality means for each important class and service context.

That distinction is central to the current CIS-DF exam. The blueprint expects practitioners to work with CMDB Health, data validation, Data Manager, duplication, lifecycle, dashboards, and operationalization. The ServiceNow Data Foundations certification is therefore less about memorizing a health score than understanding how measurable evidence is translated into remediation and sustained trust.

Start with the decisions the data needs to support

Quality is contextual. A server record used only for rough inventory may tolerate different gaps from the same class when it is used for change impact, vulnerability response, service mapping, financial allocation, or audit evidence. Before selecting metrics, identify the decisions and workflows that depend on the data. Then define which attributes, relationships, freshness levels, and ownership signals are necessary for those decisions to be safe.

This avoids the trap of optimizing metrics that are easy to calculate but weakly connected to value. Filling every optional field can increase apparent completeness while adding little operational benefit. Conversely, one missing owner or one broken service relationship can matter greatly if it prevents routing or impact analysis. Data quality becomes useful when measures are tied to consequences rather than treated as a generic scorekeeping exercise.

Thresholds should therefore be class- and use-case-specific. Ninety-five percent completeness may be acceptable for an optional descriptive field but unacceptable for an attribute that drives routing, ownership, or automated remediation. The denominator matters too: a score across every CI can hide a severe defect in the principal classes that support a critical service.

Completeness measures presence, not truth

ServiceNow CMDB Health can evaluate whether required and recommended fields are populated. That is an important baseline because missing information can block workflows, reporting, or ownership. Yet a populated value can still be wrong, copied from an obsolete source, or technically valid but meaningless. A support group field containing an existing group is complete even if that team no longer supports the CI.

The wider discipline of data quality helps explain why completeness must be interpreted alongside accuracy, consistency, timeliness, uniqueness, and validity. A metric should answer a specific question. Completeness asks whether expected values are present. It does not answer whether those values reflect reality. Teams should resist turning one dimension into an all-purpose definition of health.

Correctness is where identity, staleness, and structural integrity become visible

Correctness checks are valuable because they surface conditions that can make the CMDB misleading even when fields are populated. Duplicate CIs can split history and relationships. Stale records can represent infrastructure that no longer exists. Orphan conditions can reveal records that are disconnected from the relationships or usage the model expects. Identification-related problems can show that ingestion rules are allowing multiple representations of the same real object.

These findings should be investigated as system behavior, not merely repaired row by row. A surge in duplicates may point to a changed source identifier or an integration bypassing IRE. Staleness concentrated in one class may mean discovery coverage has changed. Repeated orphan patterns may indicate a modeling or relationship-population issue. The most valuable quality program uses defects to discover the process that produced them.

Some dimensions cannot be proven from the CMDB alone. Accuracy may require comparison with an authoritative source, a discovery observation, or a sampled physical check. Sampling is especially useful for high-value classes where a dashboard can confirm structural rules but cannot establish whether the real-world device, owner, or location actually matches the stored value.

Compliance turns organizational standards into testable conditions

Compliance measures whether records conform to policies or certification expectations that the organization has defined. This is different from asking whether a field exists or whether the CI is stale. A policy might require a particular attribute pattern, relationship, owner, lifecycle state, or other condition because a process or regulatory requirement depends on it. Those requirements should be explicit enough that teams understand what passing and failing mean.

Compliance is strongest when the standard has a named owner and a reason. If a policy exists only because someone once thought it would be useful, remediation becomes mechanical and eventually ignored. When the requirement is tied to a workflow, audit control, or operational risk, failing records can be prioritized according to impact. The metric becomes evidence for governance instead of a decorative percentage.

Relationship health matters because service context lives between records

Many high-value CMDB use cases depend on relationships rather than isolated CI accuracy. A technically correct server is much less useful if the platform cannot connect it to the application service it supports, the upstream dependency it relies on, or the service context used for impact analysis. Relationship health can expose duplicates, orphans, invalid relationship types, and other structural problems that distort how the environment is understood.

Good relationship quality starts with modeling discipline. Teams should know which relationship types are allowed, how direction is interpreted, which sources populate them, and who owns exceptions. A broad graph with uncertain semantics creates the appearance of rich context while making impact analysis less trustworthy. Fewer, well-governed relationships are often more valuable than a dense network whose meaning cannot be explained.

Profile incoming data so defects are caught before they become CMDB metrics

CMDB Health tells teams about the state of data after it is in the platform. Ingestion quality should also be measured before transformation. Track null rates, unexpected values, identifier collisions, source duplicates, reference lookup failures, and schema changes in staging data. Those signals can reveal a source-system problem before it creates hundreds of failing CIs.

Practices from data profiling are useful because they establish a baseline for what normal source data looks like. If a serial-number field suddenly becomes mostly empty or a new status value appears, an integration can alert or quarantine the condition rather than blindly load it. Prevention is cheaper than discovering the same defect later through multiple downstream dashboards.

Measure trends and recurrence, not only the current score

A snapshot can hide whether the environment is improving or repeatedly being repaired. Track how quickly defects are introduced, how long they remain unresolved, whether the same classes fail month after month, and whether remediation actually prevents recurrence. A health score that returns to green after manual cleanup is less encouraging if the same integration recreates the issue after every scheduled run.

Trend analysis also helps separate structural problems from normal volatility. A dynamic cloud class may have different lifecycle behavior from stable on-premises hardware. New service onboarding can temporarily reduce completeness while ownership is assigned. The important question is whether the system converges toward the intended quality state and whether exceptions are visible and controlled. Quality management should show learning, not just periodic correction.

Teams should also watch the denominator behind every percentage. A 95 percent completeness score across a very large low-risk class can look healthier than a 70 percent score across a small set of business-critical services, yet the second problem may deserve attention first. Class, service, health-group, and relationship views help expose where defects are concentrated. Aggregation is useful for direction, but remediation priority should follow impact rather than whichever top-line score is easiest to report.

Metric configuration should therefore be intentional. Required and recommended fields, stale thresholds, orphan logic, duplicate detection, and compliance tests need to reflect how a class is actually used. If every class inherits the same expectations, the organization can spend effort improving fields that no process consumes while missing the attributes and relationships that make a critical service understandable. Measurement becomes meaningful when the test itself is governed.

Age distribution adds another useful view. Ten new failures created yesterday usually represent a different operational problem from ten records that have been unhealthy for six months. Tracking time-to-remediate and repeated reopenings exposes quality debt that a point-in-time percentage can conceal, and it shows whether governance work is removing root causes or merely clearing queues.

Assign remediation to the people who can change the cause

A centralized CMDB team cannot sustainably fix every defect. Some problems belong to source-system owners, some to class owners, some to service owners, and some to integration engineers. Data quality workflows should route issues according to who has the authority and information to resolve them. Otherwise the platform team becomes an expensive manual translation layer between dashboards and the teams that own the actual data.

This is why data management and governance are inseparable from measurement. A metric needs an owner, a remediation path, an acceptable timeframe, and a decision about what happens when the issue cannot be fixed automatically. Data Manager policies, certification tasks, and health remediation can support that operating model, but responsibility must be defined outside the tool as well.

Prioritization should combine business criticality with defect type and scope. A stale CI that has no downstream use may be low risk, while one incorrect ownership value on a production service can misroute incidents or approvals. Segmenting quality views by principal class, service, owner, and source helps teams direct remediation where improved trust will change an operational outcome.

A useful quality program makes trust visible to data consumers

Engineers, service owners, change managers, security teams, and analysts should not need to assume that every CMDB record has the same reliability. Where possible, quality indicators should be understandable in the context where decisions are made. A service owner may need to know that ownership is verified but dependency coverage is incomplete. A change manager may care more about relationship freshness and critical infrastructure than about optional descriptive attributes.

The goal is not to produce a perfect universal score. It is to create enough evidence that people know when data is fit for a particular purpose and where uncertainty remains. ServiceNow provides dashboards, health metrics, policies, attestation, and remediation mechanisms, but mature measurement connects those capabilities to business use. Data quality is successful when better metrics lead to better decisions, clearer ownership, fewer recurring defects, and less time spent arguing about whether the CMDB can be trusted.