ServiceNow False-Positive Change Risk Alerts: The CMDB Root Cause
ServiceNow false-positive change risk alerts occur when the risk engine scores changes as high-risk based on stale CMDB relationship records — dependency links that describe infrastructure which no longer exists. When a server is decommissioned or replatformed but its CI relationships remain in the CMDB, every downstream change touching that ghost dependency chain triggers a high-risk alert. One enterprise team traced 23% of their high-risk alerts to this root cause, costing 98 hours of change advisory board (CAB) investigation time over 90 days before a discovery-sourced CMDB relationship refresh cut the false-positive rate to 4%.
How ServiceNow’s change risk engine reads the CMDB
ServiceNow’s change risk scoring engine queries the CMDB for the configuration item (CI) being changed and traverses its relationship graph. The risk score reflects four factors:
- How many downstream CIs depend on the target CI
- What services those CIs support
- What incidents are currently open against related CIs
- Whether recent changes to related CIs have resulted in incidents
Every configuration item in ServiceNow carries a set of relationship records that describe its place in the infrastructure. Every one of those records participates in risk scoring. This is where the vulnerability appears: if a relationship record wasn’t maintained after a server was decommissioned or replatformed, ServiceNow’s change risk engine scores every change touching that CI’s relationship graph as though that server is still live—even though it hasn’t been in the data center for months.
The engine has no way to distinguish between relationships that describe live infrastructure and relationships that describe infrastructure that no longer exists. From its perspective, stale is the same as current.
What false-positive alerts actually cost
One team we worked with had noticed the pattern but hadn’t connected it to a specific CMDB failure. Their change advisory board was spending roughly 40 minutes per high-risk alert on investigation, and a growing share of those investigations ended the same way: “phantom dependency — approved.”
Over a 90-day period, they counted 147 false-positive alerts. Those alerts represented 23% of all high-risk alerts the risk engine generated in that window. The direct cost to CAB efficiency was clear: 98 hours burned on noise.
But the bigger risk was harder to see. When a team becomes conditioned to dismiss one in four high-risk signals, the rigor naturally erodes. Real high-risk flags get the same treatment as phantom ones, and approval decisions begin to lean on habit rather than analysis. That’s when a real change with genuine blast radius slips through.
A 2025 EMA ServiceOps report (EMA Research, State of ServiceOps 2025) identified CMDB data quality as a direct predictor of change management outcome quality — researchers call this pattern “alert fatigue”: when false-positive rates stay high, teams stop trusting the signal entirely. Teams operating on stale CMDB data experience higher rates of change-induced incidents.
Curious how many phantom dependencies your CMDB carries right now? See how a relationship audit works →
The specific failure: a database server replatformed nine months earlier
The clearest example was a database server replatformed nine months before the investigation. The physical server had been replaced. The old CI record had never been retired. Its 14 relationship records—connecting it to application servers and middleware—had never been removed.
From ServiceNow’s perspective, this was a live database server with 14 active downstream dependencies. Any change touching that server or any CI in its relationship graph triggered a high-risk alert, even though the physical infrastructure had been gone for months.
That single CI contributed disproportionately to the 147 false positives. Because its 14 phantom relationships touched multiple service dependency chains, changes to physically unrelated infrastructure were getting flagged high-risk.
How phantom dependency chains accumulate
Phantom dependency chains form when CI records remain in the CMDB after the physical assets they describe have been retired or replaced, but their relationship records are never removed. A decommissioned server doesn’t just create one stale CI—it creates a stale node in every dependency chain it participated in. Over time, as teams decommission hardware or migrate to cloud, these ghost records accumulate.
How a discovery-sourced relationship refresh fixed it
The fix was a relationship refresh driven by Virima’s IT discovery running against the live environment and comparing discovered state against what the CMDB described.
The discovery process identified every CI currently present in the infrastructure, mapped its actual dependencies, and compared those results to ServiceNow’s relationship records. Where the CMDB carried relationships that mapped to infrastructure no longer present, those records became candidates for cleanup or retirement.
After the relationship refresh:
- 680 stale CIs were updated with current relationship data drawn from live discovery
- Phantom relationship records were removed from all 680 CIs
- The 14 legacy application dependencies on the replatformed database server were cleared
- The CI itself was formally flagged for retirement processing
In the 90-day window following the refresh, the false-positive rate dropped from 23% to 4%.
The secondary finding was equally important: phantom relationship records had been inflating ServiceNow’s change risk score baselines. The engine uses historical risk scores to calibrate future scoring. When that history includes inflated scores caused by phantom dependencies, the entire baseline shifts upward. After the relationship cleanup, the average risk score for standard changes dropped by 18 points—meaning even real changes were being scored as higher-risk than they should have been.
Why relationship accuracy matters more than process changes
You can redesign your CAB process or add approval layers, but if the underlying CMDB relationship data is stale, those process changes only add overhead without addressing the root cause. The change risk engine is only as trustworthy as the relationship data it reads.
ServiceNow integration with discovery-validated relationship data produces a materially more accurate risk signal than ServiceNow running against a CMDB that accumulates stale records. The algorithm is the same in both cases. What changes is whether the relationship graph it reads reflects your live infrastructure.
Discovery-sourced ground truth — relationship data that reflects what’s live in your environment right now — is what separates a change risk engine your CAB trusts from one they’ve been trained to second-guess.
This is why automated discovery matters operationally. ITIL change management guidance and CMDB best practices both identify relationship accuracy as one of the most operationally significant dimensions of CMDB health — the variable most directly tied to change success rates.
| CMDB Relationship State | Change Risk Signal Quality |
|---|---|
| Current, discovery-validated | Accurate blast radius; risk score reflects actual infrastructure |
| Partially stale (some ghost records) | Moderately inflated scores; occasional false-positive alerts |
| Significantly stale (unremediated decommissions) | Consistently inflated scores; 20%+ false-positive alert rates |
| Phantom dependency chains present | Baseline calibration skewed upward; low-risk changes score as high-risk |
When relationship records are discovery-validated and regularly refreshed, high-risk alerts become a signal your CAB acts on — not a heuristic they’ve trained themselves to ignore.
How to prevent phantom dependencies from accumulating
Three infrastructure lifecycle events generate most phantom dependency chains:
Server decommissioning — Add a CMDB retirement step to every decommissioning runbook. When a physical server is removed from service, its CI should be formally retired in ServiceNow and its relationship records removed. This should be a required step before the decommission ticket closes.
Cloud migration and replatforming — When workloads move from physical servers to cloud instances, the source CI does not automatically retire in ServiceNow. Build explicit CI retirement into migration runbooks as a post-migration task.
Scheduled discovery reconciliation — The teams with the lowest false-positive rates run scheduled discovery-to-CMDB reconciliation on a regular cadence, not just as a one-time cleanup. When Virima discovery runs against the live environment and compares results to the CMDB, it surfaces stale relationship records before they accumulate into the kind of phantom dependency problem described above.
Process steps at decommissioning catch the edges. Scheduled discovery reconciliation is what keeps the baseline clean between those events.
