Two owners means no owner
In most ServiceNow shops I've worked with, the configuration management database has two names on the deed and no name on the lease. IT service management wants it clean enough to route an incident to the right support group and to make a change record map to something real. Security wants it accurate enough to trust for vulnerability scoping and for the asset inventory an auditor will pull during a review. Both claims are legitimate. Neither team is fully accountable for whether a configuration item reflects what's actually running in production, and that gap is where a CMDB rots.
The rot follows the incentives, not the intent. An ITSM analyst gets measured on ticket resolution time and change success rate. A security analyst gets measured on mean time to remediate and how much of the estate they've scanned this cycle. Nobody's scorecard has a line for closing the configuration item when the server got wiped. Updating a CI after a decommission produces no ticket, satisfies no SLA, and shows up on nobody's dashboard, so it slides to the bottom of two different queues at once instead of the top of one.
This is also why the fix rarely comes from a policy memo. I've watched teams write a data governance standard that says both departments share responsibility for CMDB accuracy, sign it, and change nothing. A shared claim with no single accountable owner doesn't get more accountable because it's written down. A CMDB is master data, and the same lesson shows up in ERP master data programs that split ownership across finance and operations and end up with neither side maintaining the customer or vendor record.
A decommissioned server that wouldn't retire
Here's the failure I've seen enough times to stop being surprised by it. Infrastructure ops decommissions a server, say a web front end named WEBPRD-014, powers it down, pulls it from the rack, and closes the decommission ticket. The template used for that closure never included a step to update the CI, so the record in cmdb_ci_server sits with install_status still set to Installed. Nobody notices, because checking isn't anybody's job. Three months later that CI is still marked active, still carrying its last known IP, still sitting in the CMDB as if it were serving traffic.
Then a critical CVE lands and security runs a scan. The vulnerability response module ties the vulnerable item back to that cmdb_ci reference, and WEBPRD-014 gets flagged for remediation. Someone opens a task, assigns it to the infrastructure team, and that team spends the better part of a day trying to find a box that no longer exists in the building. They check the rack, then the hypervisor cluster, before someone finally remembers the server was decommissioned back in January.
The cost isn't just that lost day. The remediation SLA clock keeps running against a target that was never real, which drags down the team's remediation numbers for a quarter they had nothing to fix. Analysts scoping the same CVE across a naming convention assume the range around WEBPRD-014 is already accounted for and move on, so a live host nearby gets less scrutiny than it should. And when the next PCI assessment pulls the asset inventory report, the auditor finds retired hardware still listed as in-scope and opens a finding that takes two more weeks of back and forth to close. None of that shows up as an incident. It just shows up as time nobody gets back, which is exactly why a real retirement list matters as much for a single server as it does for a whole legacy application.
Who should own reconciliation when the scan and the record disagree
When a discovery scan and a change record disagree about what a server is, the instinct is to treat it as a technology problem, rerun the Identification and Reconciliation Engine, adjust a precedence rule, and hope the conflict resolves itself. It won't, because the disagreement is a business question dressed up as a data question. Discovery tells you what exists right now. The change record tells you what was supposed to happen. Those are different facts, and a CMDB that treats them as competing versions of the same fact will always have a tie it can't break on its own.
My rule, and the one I push toward on every engagement, is that discovery wins on current state and existence. If a scan says a host is gone, it's gone, regardless of what the change record says should still be running. The change record wins on intended state, what the environment is supposed to look like once an approved change lands. Reconciliation is the discipline of reading both and deciding which one describes reality today, and that discipline needs an owner who isn't the ITSM director trying to protect change velocity and isn't the security director trying to protect scan coverage numbers. It needs a configuration manager or CMDB steward role, reporting outside both chains, measured specifically on CI accuracy and reconciliation turnaround.
Part of why this keeps breaking is that CIs get identified by attributes that drift, a hostname that gets reused or an IP that gets reassigned before anyone updates the record. The same problem that pushes finance and IT toward durable business keys for customer and vendor records applies just as directly to a server. A CI needs a key that survives a rename and a re-IP, or reconciliation turns into a guessing game every time the network team touches a subnet.
A working split between ITSM and security
The arrangements that actually hold share a few features. ITSM keeps day to day ownership of creating and updating CIs through the normal request and change process, because that team touches the most records and sits closest to the work. Security gets standing read access to the full CMDB, not a filtered export, plus a formal veto over closing any CI tied to an open vulnerability, so a record can't disappear out from under an active remediation.
A named steward, sitting under the architecture or platform function rather than under either ITSM or security, runs a weekly discovery versus CMDB delta report and routes each mismatch to whichever team owns that asset class, with a five business day SLA to resolve it. The steward doesn't re-review the whole table every week, just the exceptions the report surfaces, which keeps the job small enough that someone will actually keep doing it. The monthly meeting between ITSM and security covers that exception queue and nothing else, no status slides, no CMDB health score nobody trusts.
Decommission requests get the install_status flip built into the workflow itself, enforced by the platform rather than left as a manual checkbox on a closure form. If the server can't be marked retired until that step runs, nobody has to remember to do it. That single change is the difference between a WEBPRD-014 that disappears from the CMDB the day it's unplugged and one that keeps surfacing in a vulnerability report for a quarter. Teams that get this right tend to be the same ones that already treat security specialists as part of the go-live team rather than as a downstream reviewer who shows up after the CMDB decisions are already made.
Pull the delta report before you argue about ownership
If your CMDB has this problem, and most that serve both ITSM and security eventually do, don't start with a governance committee. Pull the discovery versus CMDB delta report this week, however rough it is, and count how many CIs are marked active with no discovery hit in the last thirty days. That number is your actual exposure, not a guess.
Name one person to own the exception queue, give them a five business day SLA, and put the install_status flip into the decommission workflow before the next server goes dark. The CMDB won't clean itself up through a shared responsibility statement, and it won't clean itself up before the next scan runs against a server that's already gone. If you're planning to let an agent read that same data to make decisions on its own, get the CMDB right before the agent does, because an automated system will trust a stale CI exactly as much as a human analyst does, which is to say completely, and exactly once.
