CIS-DF: Six CMDB Health Metrics and Data Manager Policies

ServiceNow CIS-DF assigns 35% of its exam coverage to Govern. That weighting makes sense: a configuration management database is not trustworthy because every device has a row, but because the organization can explain which records are incomplete, stale, duplicated, wrongly related, or no longer managed—and can correct them without damaging valid service data. The current CIS-DF exam explicitly tests CMDB Health metrics, dashboards, principal classes, the deduplication wizard, CI lifecycle attributes and Data Manager policy selection.

Two separate decisions often get mixed together. CMDB Health helps identify and measure specific defects; CMDB Data Manager organizes policy-driven lifecycle and validation work. A failing completeness metric is not necessarily a reason to retire a CI, and a retired device may still appear in health reports because retirement alone does not remove it from CMDB processing. Understanding that distinction is the difference between making the dashboard look better and making the data more dependable.

This article uses a fictional estate containing Linux servers, an application service, a database and a few stale entries. It goes beyond the concepts in CMDB Health foundations and data certification and remediation by following each failing indicator to a particular corrective decision. Apply the examples only in a nonproduction ServiceNow instance using synthetic CIs; archive and delete policies can have lasting consequences if aimed at real records.

The six classic CI health metrics

The CIS-DF blueprint calls out six metrics making up the core CMDB health score. ServiceNow’s current CMDB Health documentation explains them within the three established CI KPI groups: Completeness, Correctness and Compliance. Completeness evaluates required and recommended fields. Correctness evaluates duplicate, stale and orphan CI indicators. Compliance relies on appropriate audit checks. Modern ServiceNow documentation also reports a separate Relationships health area, including orphan, duplicate or stale relationships. Do not collapse the relationship measurements into one of the six familiar CI metrics.

These indicators need configuration and interpretation. A required field is not always the same as a recommended field. Out of the box, the recommended-field list can be empty until a team configures it or uses supporting jobs. A class with a missing recommendation should not automatically be described as violating a dictionary-mandatory field. Similarly, a stale threshold may have a default, but organizations can override the timing by class to reflect different update patterns.

For compliance, a dashboard cannot report meaningful audit evidence when the expected audits have not been activated and run. A blank result can mean a missing control or collection setup, not that every CI passed. Before acting on a percentage, check what the metric measured, which class or health group it included and when it last ran.

Run a safe metric investigation instead of guessing

Imagine five synthetic server CIs. One lacks a required serial number, one lacks a configured recommended owner, one is a duplicate of another record, one has not been updated within the relevant stale threshold, and one is not connected to the service expected by an orphan rule. A useful administrator should predict which health checks may fail before looking at the dashboards. Do not force one metric to explain all five defects.

Start with the CI class and its applicable health rules. A serial number requirement may differ for hardware versus a logical service record; a logical application service may not have the same discovery cadence as a physical server. Assign meaningful principal classes and thresholds rather than applying inappropriate mandatory fields to every child class just to increase a percentage.

Then inspect a failing CI. For a missing source-populated attribute, the best fix could be upstream integration mapping or field normalization. For a human-owned attribute, assign the right steward or start an appropriate certification task. For duplicates, inspect identification rules and the incoming source behavior before choosing a merge. For staleness, confirm whether the device has actually been decommissioned or simply stopped reporting due to a collection failure.

After the correction, rerun or wait for the supported metric collection and inspect the result. Confirm that the real business consumer can still use the CI and its relationships. A dashboard score is secondary evidence; the primary goal is that incidents, changes, asset processes and service maps can rely on the corrected data.

Why the Relationships health area also matters

ServiceNow’s newer CMDB Health documentation describes relationship-quality indicators beyond the six classic CI health metrics. Duplicate relationship checks examine repeated parent/child/type combinations. Orphan relationship checks look for missing endpoints. Stale relationship indicators consider related CIs that no longer reflect current reality. Suggested relationship, containment and hosting rules may provide further compliance context.

Consider a database CI whose relationship to an application service was deleted during a reconciliation. Its own required attributes may be present, so a field-completeness result could look acceptable. The service map would still be wrong. The appropriate remedy is to restore the correct relationship from the reliable source and verify its direction and type—not to add irrelevant fields to the database CI.

When discussing “six metrics” on the exam, use the official exam and ServiceNow configuration context rather than assuming every dashboard contains only those six elements. Core CI correctness/completeness/compliance checks and the broader relationship health experience can coexist. Recognizing their difference helps answer scenarios about an accurate CI with an inaccurate dependency map.

Know the Data Manager policy types by their outcomes

CMDB Data Manager uses policy-driven operations to manage the lifecycle and validation of CIs. The correct choice depends on the business requirement and whether the result must remain visible, recoverable or auditable. ServiceNow’s current documentation distinguishes Retire, Archive, Delete, Attestation, Certification and related-entry cleanup. Treat these as different actions rather than variants of “clean up the CMDB.”

An archive or delete policy is not a safe substitute for an IRE identification correction. If two source feeds create duplicates, first understand which records represent the same asset, which references they carry and which rule caused the duplication. Removing a duplicate before fixing the feed can simply guarantee the duplicate reappears tomorrow.

For lifecycle policy types Retire, Archive and Delete, current ServiceNow documentation requires an active retirement definition for each targeted CI class. An inherited definition may apply to child classes unless they have a more specific rule. Archive and Delete policies are designed to target CIs that are already considered retired under the relevant definition. This ordering is part of the control, not unnecessary bureaucracy.

Scenario: a server disappears from Discovery

A fictional Linux server stops appearing in nightly Discovery. The infrastructure owner says it may have been decommissioned, but the application team still sees it in a dependency map. A rushed administrator proposes a Delete policy for every CI not discovered for seven days. That would be dangerous: a temporary MID Server outage, credential error or network change could cause valid production servers to be misclassified as obsolete.

The safer first step is investigation. Check ingestion health, last discovered timestamp, source coverage and the owner’s confirmation. Determine whether the CI has active relationships, incidents, asset associations or pending changes that require preservation. If the server really is retired, use a class-appropriate retirement definition and a scoped Retire policy. Decide separately when the organization may archive its record and how long the archive must remain recoverable.

In your test instance, preview the eligible CI set, inspect exclusions and use a small controlled sample before publishing a policy. ServiceNow Data Manager can generate tasks or approvals according to configuration. If the Managed by Group field is absent or a task is rejected, administrator intervention may be required. Be explicit about which person or group can approve the change and how the result will be monitored.

Later, verify that the server is no longer incorrectly presented as an active application dependency, while its historical evidence remains available under the agreed retention policy. Confirm the application owners and incident responders can still understand what changed. A green dashboard that silently destroyed business context would be a poor governance outcome.

Scenario: the same device appears in two integrations

Now imagine a Discovery feed and a third-party integration both creating a CI for the same physical server. The serial number is similar but formatted differently, and the feeds disagree about ownership. The appropriate starting point is the identification rule and data normalization. Which attributes reliably establish identity, and how should the incoming payload be processed through IRE?

If duplicates already exist, review affected records, referenced relationships and authoritative data. The deduplication workflow may help remediate them once their equivalence is established. However, merging before resolving source rules can break references or lead to recurrence. Assign a source owner to correct the incoming format and a data steward to validate the surviving CI.

This scenario combines Configuration, Ingest and Govern even though the exam reports them as separate weighted domains. An answer focused only on the deduplication wizard may overlook why the duplicate was created. An answer focused only on stopping an import can leave bad records in the existing dataset. Sound remediation solves both the accumulated defect and its continuing cause.

Dashboards and playbooks should produce owned work

CMDB Workspace and health dashboards help administrators find failing classes, owners and remediation tasks. The CSDM Data Foundations dashboard provides additional maturity-based indicators for service data, while the CMDB Data Foundations dashboard may expose other quality practices and playbooks. These related surfaces do not all measure the same thing. An organization should map each metric to the accountable source, stakeholder and operational consequence before deciding on a fix.

For example, a “business service offering missing a relationship to a service instance” finding is a service-model problem. It may require a stakeholder to clarify the intended offering and a CMDB owner to create the correct dependency. A server duplicate problem may instead require IRE and the source integration team. A useful remediation playbook explains the indicator, its operational significance and steps to correct it, but the team still needs to test the result.

Record recurring failure volume and age, not just one healthy-looking snapshot. If a field is repeatedly blank, assign an owner to improve the source process. If an old CI lifecycle rule creates unwanted archive targets, review the class definition and test it. Governance becomes real when it changes repeatable behavior.

How this fits the CIS-DF exam

When the scenario involves missing mandatory values, think Completeness Required. When optional recommended fields are unfilled, verify what the instance actually classifies as recommended. When an identification rule matches several records, think Duplicate Correctness and root-cause IRE review. When a CI is old, distinguish stale source collection from genuine retirement. When a policy must verify owner data, certification is not the same as deleting obsolete records.

A strong candidate can name the failing metric, the correct policy type, the responsible owner and a way to demonstrate that the correction improved trusted service information. Those four pieces are more valuable than memorizing an interface sequence, because actual organizations and ServiceNow releases differ. The 35% governance weighting reflects the depth of these decisions: quality needs definitions, recurring measurement, safe lifecycle operations and accountable people.