CMDB quality programs often fail in one of two ways. Some rely on dashboards that show scores but do not change behavior. Others rely on periodic human cleanup without a consistent way to measure whether quality is improving. ServiceNow provides two complementary mechanisms—CMDB Health and Data Certification—that become valuable when they are connected to ownership, evidence, and remediation.
The current ServiceNow CIS-DF certification emphasizes operationalizing the CMDB and CSDM. Operationalization means that quality is continuously observed and acted upon. It is not enough to define a policy saying data should be accurate.
CMDB Health automates checks against defined conditions. Data Certification creates a human review process for information that requires attestation. Together they can create a control loop: machines find measurable failures, people validate what cannot be inferred safely, and remediation improves the sources or processes that created the problem.
CMDB Health converts vague quality concerns into testable conditions
ServiceNow evaluates CMDB health through dimensions such as completeness, correctness, compliance, and relationship health. These categories matter because “bad data” is too broad to troubleshoot.
Completeness asks whether required or recommended information is populated. Correctness can expose conditions such as duplicates, stale CIs, or orphaned records. Compliance evaluates data against defined certifications. Relationship health checks the structure connecting CIs, including problems such as duplicates or orphan relationships.
Each metric gives the organization a starting point. It does not automatically explain why the failure occurred, but it narrows the problem enough to assign investigation.
A score is not a control until someone owns the response
Dashboards are easy to publish and easy to ignore. A health score becomes operational when thresholds trigger action, failures create work for accountable teams, and repeated issues are reviewed as process defects rather than tolerated as background noise.
ServiceNow allows health metrics to create remediation tasks and assign them to groups. The design choice is important: tasks should go to the team that can correct the cause. Sending every failure to the CMDB administrators creates a cleanup queue and hides the fact that the source or owning process may be defective.
This connects directly to data-quality accountability. The CMDB team can operate the health framework, while domain owners remain responsible for the data produced by their systems and processes.
Data Certification is useful where automated rules cannot prove truth
Some facts cannot be validated reliably by comparing fields to a technical rule. Ownership is a good example. A record may contain a syntactically valid owner who left the organization or no longer manages the service. A relationship may be structurally allowed but no longer reflect the real operating model.
Data Certification creates policies and tasks that ask people to review and attest to defined data. This is stronger than an informal spreadsheet review because the certification process is part of the platform, has assigned work, and can be measured over time.
The key is to reserve human certification for decisions that require human context. Asking people to certify data that can be validated automatically creates unnecessary effort and encourages rubber-stamping.
Certification policy should target consequential data
Not every field deserves the same review cadence. The most valuable certification targets are attributes and relationships whose inaccuracy creates downstream risk: service ownership, criticality, lifecycle state, key dependencies, support groups, or other information that drives decisions.
The review frequency should match how quickly the information can change and how costly an error would be. A highly dynamic operational attribute may need automated observation rather than quarterly human attestation. A service owner assignment may justify periodic certification because the platform cannot infer organizational responsibility perfectly.
A strong policy therefore begins with the decision the data supports, not with a desire to certify more fields.
Health metrics can reveal where certification is worth the effort
CMDB Health can identify classes or services with recurring problems. That evidence can guide targeted certification. If ownership completeness is high but service relationships repeatedly fail, a certification campaign focused on owner fields may add little value. If stale records cluster in one source, the better fix may be source retirement logic rather than human review.
This is how the two mechanisms reinforce each other. Automated metrics identify patterns. Certification adds human judgment where needed. The results then inform changes to source systems, integrations, CSDM modeling, or governance.
The objective is not to maximize health scores or certification completion rates. It is to reduce uncertainty in the data that operations depend on.
Any metric can be improved cosmetically. Teams can populate required fields with placeholder values, relax thresholds, exclude difficult classes, or certify records without meaningful review. The dashboard becomes greener while trust remains low.
Governance should therefore ask whether the metric predicts better operational behavior. Are incident teams finding the right owners faster? Are change impact assessments more accurate? Are duplicate-related failures declining? Are service maps becoming more reliable?
Outcome checks discourage gaming because they connect data quality to the work the CMDB exists to support.
Exceptions need reasons, owners, and expiry conditions
Some health failures are legitimate. A class may not have a recommended attribute because the source cannot provide it. A relationship may be temporarily incomplete during migration. A certification task may be delayed because ownership is being reorganized.
Ignoring the metric is not governance. The exception should record why the rule cannot currently be met, who owns the risk, what compensating control exists, and when the exception will be reviewed.
This keeps metrics honest. The organization can distinguish known accepted gaps from uncontrolled defects.
Review trends, not only snapshots
A single health score can be misleading. A class may show 98 percent completeness while the same two percent fails every month. Another may show a lower score that is improving quickly because a new source is being remediated.
Trend analysis reveals whether controls are working. Look at recurrence, time to remediation, failure concentration by source or owner, certification completion behavior, and the rate at which new defects appear.
The useful question is not “What is our score?” but “Is the system producing less uncertainty over time?”
Feed quality failures back to the mechanism that created them
The most important step is upstream correction. A missing attribute should lead to a source or process review. Duplicates should lead to identification analysis. Conflicting values should lead to reconciliation review. Stale CIs should lead to discovery or retirement logic. Relationship defects should lead to modeling or mapping improvement.
Manual fixes are sometimes necessary, but they should be treated as containment. If the same failure reappears, the control loop is incomplete.
This is where broader configuration-management practices support CMDB health: reliable data comes from disciplined lifecycle processes, not heroic cleanup.
ServiceNow also provides a CMDB Data Foundations dashboard that groups checks around best practices, customizations, data-management practices, and ITSM use. This can help teams look beyond individual CI metrics and ask whether the implementation itself follows patterns that protect long-term CMDB integrity.
That broader lens is useful because a technically healthy class can still exist inside a fragile operating model. Excessive customization, poorly governed imports, or weak use of CMDB data in ITSM processes can undermine the value of the foundation even when many records pass field-level checks.
The right response is to connect these views rather than chase each score independently.
Operational quality is a closed loop
For CIS-DF candidates, the durable model is a loop: define the data that matters, measure what can be tested automatically, certify what requires human judgment, assign failures to accountable owners, remediate the mechanism, and review trends to confirm improvement.
The ServiceNow platform provides the tools, but governance determines whether they change behavior. A green dashboard is not the goal. A trusted CMDB that consistently supports incidents, changes, services, security, and architecture is the goal.
Data Certification and CMDB Health become valuable when they make that trust explainable. The organization can show which controls test the data, who reviewed what automation cannot prove, how exceptions are handled, and whether recurring defects are becoming less common. That is what turns metrics into an operating discipline.
A certification task is only useful if a negative answer has an operational consequence. If an owner says a CI attribute or relationship is wrong, the process should route the defect to someone who can correct the source, model, or record and then confirm that the fix persisted.
Without that closure, certification becomes a survey. The organization learns that data is wrong but does not improve the mechanism. A mature policy therefore defines remediation ownership, expected response time, escalation for overdue work, and how recurring failures influence governance decisions.
Aggregated scores are useful for trend reporting, but they can hide concentration risk. A small number of critical services may contain most failures while the enterprise average remains healthy. Reviews should therefore drill into classes, services, owners, and sources rather than relying only on a single overall percentage.
Context also protects against false alarms. A metric failure on a low-impact retired class may deserve less urgency than a smaller failure on production application services. Operational prioritization should combine health evidence with criticality and use.
