A patch compliance figure is a fraction. The patching tool supplies the top half: servers that received the update. The configuration management database (CMDB) supplies the bottom half: servers that should have. When CMDB patch compliance reporting runs against configuration items (CIs) that are missing, duplicated or long gone, the sum still produces a confident percentage. It describes an estate that doesn't exist. And the servers that never reached the CMDB are exactly the ones nobody patched, sitting outside the denominator where they can't pull the score down.
What follows covers the four ways that bottom half goes wrong, how to measure each one, and the controls we put in place so nobody signs off a compliance figure without knowing what it was counted against.
Where the denominator in CMDB patch compliance comes from
Most compliance reports scope their population with CMDB filters. Server classes, operational status of operational, perhaps an environment value of production. Every one of those filters is an attribute, and every attribute has a source that populated it.
The report inherits the accuracy of each source. It has no way of knowing that one was wrong.
Reports tend to side with the CMDB over the scanner's own host list, and for a sensible reason. The CMDB holds the support group and the owner, which is how a vulnerable item gets routed to someone who can fix it. The side effect is that CMDB gaps become reporting gaps without anyone choosing that.
| What the CMDB holds | What's actually true | Effect on the score |
|---|---|---|
| Nothing | A live server exists | Server is outside the denominator, so the score rises |
| Two CIs | One server | One record carries the patch data, the twin looks unpatched or matches nothing, so the score moves in either direction |
| An operational CI | The server was decommissioned | It never patches, the score falls, and the team learns to ignore the report |
| A CI in the wrong class, or with a blank environment | A production server | It drops through the report filter and behaves as though it were missing |
Only one of the four makes the number look worse. That's why the other three survive for years.
Missing CIs inflate the score
A server the CMDB has never heard of is invisible to every report built on it. Nobody raises a vulnerable item against it, so nobody is late fixing one.
To find them, reconcile the CMDB server population against at least two inventories that were built independently of it. The hypervisor and cloud provider inventories are the most reliable, ideally brought in through the relevant Service Graph Connector so the records share identifiers with discovery. The vulnerability scanner's host list is the second.
Match on serial number first, then on host name and network address, and sort every server into one of four groups:
- Present in the CMDB and both inventories
- Present in the inventories but not the CMDB
- Present in the CMDB but neither inventory
- Present in the scanner only
The second and fourth groups are your hidden population. If you run ServiceNow Vulnerability Response, look at the detections that the CI lookup rules couldn't match. Each one is a host the scanner has seen and the CMDB hasn't, and it deserves an owner within the week.
Then work out why discovery missed them. In our experience the answer is usually unglamorous: an address range the network team added that never made it into a discovery schedule, or a credential that stopped working and has been failing quietly ever since. Compare the discovery schedules against the network team's current address plan, and read the discovery error log for authentication failures before you look anywhere else.
Duplicate CIs make the number unreadable
Duplicates are harder to spot because the total looks healthy. There are plenty of servers. Too many, in fact.
On one estate running to tens of millions of CIs, a cloud security tool had been connected to the CMDB on the understanding that it was the definitive source for cloud servers. The tool exposed no identifier that matched anything discovery had already written. Every cloud virtual machine it sent therefore arrived as a brand-new CI.
Because the Identification and Reconciliation Engine had nothing to match on, it didn't treat the new records as duplicates, and they never appeared in the de-duplication tasks. A cloud administrator found the problem by noticing the CMDB held twice as many instances as the tool itself reported. By that point change requests had been raised against the wrong CIs, and impact assessment had missed what those changes touched.
The fix was to stop that tool creating cloud server CIs and bring them in through the Service Graph Connector for Amazon Web Services instead. Everything else the tool supplied carried on flowing in.
Apply the same logic to patch reporting. When every real server exists twice, the compliance figure is averaging two records that describe one machine, and at most one of them is receiving patch data. The percentage stops meaning anything.
Three checks catch this before it reaches a report:
- Run a duplicate report on server classes grouped by serial number, and separately by cloud object identifier. Do it before you change any identification or reconciliation rules, or the rules will be tuned around the duplicates.
- For every integration that writes to server classes, name the identifier it supplies that the identification rules can actually use. If you can't name one, it shouldn't be allowed to create CIs in that class.
- Compare the count per source against that source's own console. A doubled number is the cheapest alarm you'll ever get.
We cover the matching mechanics in more depth in our article on ServiceNow identification rules.
Stale CIs teach people to ignore the report
A server decommissioned long ago but still marked operational will never report a patch. It sits on the non-compliant list indefinitely.
The damage isn't the lost percentage point. It's what the list does to the people reading it. When a report is padded with machines that no longer exist, the team fixing vulnerabilities learns to skim past anything that looks unfamiliar, and a genuinely live, genuinely unpatched server gets skimmed past along with the ghosts.
Set a staleness rule tied to your discovery schedule. If a server CI has missed two consecutive discovery cycles while still marked operational, it goes to its owner for confirmation. CMDB Data Manager can run this as a policy with an attestation step, so the decision sits with someone who knows the machine.
Retire rather than delete. The CI's vulnerability and change history is audit evidence, and deleting it removes the record of what was open when the server went away.
Misclassified CIs fall through the filter
A production server recorded in a generic computer class, or with a blank environment field, is present in the CMDB and still absent from the report. It behaves exactly like a missing CI, except that a count of the CMDB won't reveal it.
Two measurements find these:
- A count of CIs sitting in a parent class with no more specific class applied. Anything that should be a Linux or Windows server and isn't will never match a report scoped to those classes.
- Completeness on the exact attributes the compliance report filters on. If the report scopes by environment, operational status and support group, measure how many server CIs have each of those populated. General completeness scores won't tell you this, because they weight attributes the report never uses.
Correcting the class isn't a simple field edit, and it has consequences for relationships and history. Our guide to CI reclassification in ServiceNow walks through doing it safely.
Controls to apply before anyone signs off a compliance figure
Measurement finds the problem once. The operating model stops it coming back.
Publish the denominator with the percentage. Every compliance report should carry four supporting numbers: the reconciled server count against the independent inventory, the open duplicate count, the stale count, and the unclassified count. A high percentage next to a large unreconciled gap reads very differently.
Split the accountability. The security team owns the top half of the fraction. The configuration manager should own the bottom half, and attest to it before the figure goes to a risk committee or an auditor. Write that into the RACI (responsible, accountable, consulted, informed) matrix explicitly, because by default nobody owns it.
Put a gate on new data sources. Any integration that will write to server classes goes through the change advisory board with its identifier named, before its first import. That single question would have stopped the duplicate problem above on day one.
Register what discovery can't reach. Appliances and locked-down systems that no probe can touch still need patching. Record them manually with a named owner and a review date, so they sit inside the denominator rather than outside it.
Track the gap as a key performance indicator (KPI). The difference between the CMDB server count and the independent inventory count, trended monthly, tells you whether coverage is improving faster than the estate is changing. It also gives the configuration manager a number to take to a budget conversation. For how this fits alongside completeness, correctness and compliance measures, see The 3 Cs of a CMDB.
How Apex helps
Our discovery and integration coverage review establishes what's missing from your estate view, where it's missing, and why. We reconcile your CMDB server population against independent inventories, trace each gap back to the discovery schedule, credential or integration that caused it, and show you which of your compliance reports are counting against an incomplete denominator. It's scoped at the initial consultation against your estate and requirements.
Where duplicates are the bigger problem, our data quality assessment measures de-duplication, normalisation and reconciliation against weighted critical success factors, KPIs and metrics, and tells you which identification and reconciliation rules are letting records through.
You can book a CMDB diagnostic call to talk through what your compliance figure is actually counting, or book a meeting with one of our consultants.
Frequently asked questions
Why can bad CMDB data make patch compliance look better than it is?
Compliance is usually calculated as patched servers divided by servers in scope, and the CMDB defines the scope. A server missing from the CMDB is missing from the calculation, so its unpatched state never counts against the score. The less complete the CMDB, the more flattering the figure can become.
How do I check whether my CMDB is missing servers?
Reconcile the CMDB server population against at least two independently built inventories, such as your hypervisor or cloud provider inventory and your vulnerability scanner's host list. Match on serial number, then host name and network address. Anything present in those inventories and absent from the CMDB is outside your compliance reporting.
Do duplicate CIs raise or lower the compliance score?
Either, which is what makes them dangerous. Typically one record receives patch data and its twin doesn't, so the twin looks unpatched, but a scanner may match to either record. The result is a percentage that no longer corresponds to real machines in either direction.
Should stale server CIs be deleted?
Retire them rather than deleting them. The CI's vulnerability and change history is audit evidence. Use a staleness rule tied to your discovery schedule and route each candidate to its owner for confirmation before retiring it.
Who should be accountable for the patch compliance denominator?
The configuration manager, with an explicit attestation before the figure is reported. The security team owns whether servers are patched, but it rarely controls which servers the CMDB believes exist. Writing that split into the RACI matrix closes a gap that otherwise belongs to nobody.
Book a free call to discuss how Apex can help you on your journey to a better CMDB
ServiceNow Identification Rules: How CMDB Duplicate Prevention Really Works
CMDB Health Assessment: What It Involves And What It Risks
