How does your organization manage missing CIs?

[aditityagi]

While advanced CMDB capabilities like Service Mapping, CSDM alignment, and Now Assist are key milestones, I want to address a more fundamental question: How do we manage known assets that fail onboarding (due to credential issues, missing data, etc.) and become invisible to the CMDB despite running in the environment?

This raises a crucial governance debate: Should a CMDB only contain fully discovered, validated CIs to maintain trust, or should it use a "Missing CI Registry" or placeholder records to track known gaps with assigned ownership and target resolution dates?

While CMDB maturity is measured by Completeness, Correctness, and Compliance, perhaps we should also measure the "Known unmanaged CI percentage." A healthy CMDB requires visibility into what exists outside the database, making data quality a shared responsibility across technology towers.

I would love to hear from the community:

1.  How does your organization manage missing CIs?
2.  Do you maintain a Missing CI Registry or Exception Register? excel tracker or in servicenow ?
3.  Do you use placeholder/candidate CIs, or only fully discoverable CIs?
4.  What KPIs do you use to measure unmanaged CI risk?

Looking forward to your insights.

[vaishali231 · Accepted solution]

Hey @aditityagi 

A CMDB should represent trusted configuration data, but "not knowing" is also valuable information. Ignoring assets that failed discovery creates a blind spot that can be more dangerous than having an identified exception. The key is ensuring that unknown or incomplete items are clearly distinguished from trusted production CIs.

My thoughts on your questions:

1. How does your organization manage missing CIs?

The most successful implementations I've seen treat failed onboarding as an operational process rather than a CMDB problem.

Typically:

Discovery identifies a target but cannot classify or populate it.

An exception record is automatically created.

The exception is assigned to the responsible infrastructure/application owner.

The owner resolves credentials, firewall rules, MID Server issues, DNS problems, or missing identifiers.

Once discovery succeeds, the exception is automatically closed.

This creates accountability without polluting the CMDB with inaccurate records

2. Do you maintain a Missing CI Registry or Exception Register?

Yes, but preferably inside ServiceNow rather than in Excel.

Using ServiceNow provides:

Assignment groups and ownership

SLA tracking

Aging reports

Dashboards

Workflow automation

Audit history

Many organizations implement a custom table such as:

Discovery Exceptions

CMDB Onboarding Exceptions

Missing CI Registry

Unmanaged Asset Register

Each record might contain:

Host/IP

Asset identifier

Discovery source

Failure reason

Last attempted discovery

Business owner

Technical owner

Priority

Target resolution date

Current status

Excel works temporarily but quickly becomes outdated and disconnected from operational processes.

3. Do you use placeholder/candidate CIs, or only fully discoverable CIs?

It depends on the use case.

Generally, I would avoid creating production CIs solely because discovery failed.

A better approach is:

Production CMDB → only validated CIs

Exception Register → systems known to exist but not yet onboarded

Placeholder CIs can create challenges:

Duplicate CIs later

Incorrect relationships

Poor Service Mapping

Reduced trust in CMDB data

Difficult reconciliation

However, temporary placeholder or candidate CIs may be justified for:

Critical business services

Audit requirements

Planned onboarding

Large migration projects

These should be clearly identified with a lifecycle state such as:

Candidate

Pending Discovery

Onboarding

Unverified

and excluded from operational reporting until validated.

4. What KPIs do you use to measure unmanaged CI risk?

Beyond traditional CMDB Health metrics, I would recommend tracking operational governance metrics such as:

1. Number of known unmanaged assets
2. Percentage of infrastructure not represented in CMDB
3. Discovery success rate
4. Discovery failure rate by reason
5. Average age of onboarding exceptions
6. Exceptions older than 30/60/90 days
7. Credential-related failures
8. Network connectivity failures
9. Identification/Reconciliation failures
10. Assets discovered but not classified
11. Business services with unmanaged dependencies
12. Mean Time to Onboard (MTTO)

One metric I particularly like is:

Known Unmanaged CI % = (Known unmanaged assets ÷ Total known assets) × 100

This measures visibility rather than perfection. An organization with a 98% complete CMDB but zero awareness of the remaining 2% may actually be at greater operational risk than one with a 95% complete CMDB and full accountability for every missing CI.

Overall, I believe the CMDB should remain a trusted source of validated configuration data, while a dedicated CMDB Exception Registry (or Missing CI Registry) tracks everything that is known but not yet manageable. This keeps the CMDB clean while ensuring unmanaged assets are visible, owned, measurable, and actively remediated. In my view, CMDB maturity should not only be measured by Completeness, Correctness, and Compliance, but also by the organization's ability to identify, track, and reduce unmanaged CI risk over time. This shifts CMDB ownership from a tooling exercise to an enterprise governance practice where infrastructure, application, security, and platform teams all share responsibility for improving data quality.

*********************************************************************************************************

If this response helps, please mark it as Accept as Solution and Helpful.

Doing so helps others in the community and encourages me to keep contributing.

Regards

Vaishali Singh

Servicenow Developer
Linkedin - https://www.linkedin.com/in/vaishali-singh-2273361bb