Non-Discoverable CIs — Managing What Automation Cannot See

The Discovery Blind Spot

You have now learned the major automated ingestion pathways: Import Sets batch data in, Service Graph Connectors poll APIs, and Discovery (coming in Part 3) actively scans network devices. Together these tools can automatically populate a large portion of your CMDB.

But consider what they cannot find:

• A network cable running from Switch A port 12 to Server B port 1 — it has no IP address, no API, no agent
• A software license agreement — a legal document, not a network device
• A business application like "Customer Order Management" — it's a service composed of multiple CIs, not a single discoverable thing
• A vendor contract for hardware maintenance
• A printer with SNMP disabled and no management agent
• A UPS (uninterruptible power supply) in a server room — critical dependency, zero network presence
• An air-gapped system — physically isolated from any network for security reasons

If these items aren't in your CMDB, your impact analysis is wrong. "If I take down Server X, what's affected?" will give an incomplete answer because the cable connecting Server X to the core switch isn't tracked. Non-discoverable CIs fill this gap.

Categories of Non-Discoverable CIs

Understanding the categories helps you recognize non-discoverable CI scenarios on the exam.

Physical Infrastructure — No Network Presence

These are physical items that exist in your data center or office but have no IP address or management interface that automated tools can reach.

• Network cabling and patch panels: The physical wires connecting devices. Critical for physical impact analysis.
• Power distribution units (PDUs): Some PDUs have management cards; many do not.
• Uninterruptible Power Supplies (UPS): Provide backup power; physical failure affects everything connected.
• Rack units (empty rack space): Capacity planning requires knowing available rack space.
• Physical security devices: Badge readers, cameras, door locks in server rooms.
• KVM switches: Keyboard/video/mouse switches that connect to servers without a network connection.

Software and Licenses

• Software license records: Tracks purchased license entitlements, not installed software instances. Discovery can find installed software but not the license agreement itself.
• Subscription records: Cloud service subscriptions, SaaS agreements
• Certificates: TLS/SSL certificates — some scanners can detect these, but many can't

Logical and Organizational Constructs

These CIs exist as concepts or groupings, not physical objects.

• Business Applications / Business Services: "Payroll Processing" is a service composed of many CIs. No scanner creates it — a human must define which CIs belong to it.
• IT Services: Higher-level service definitions that map to customer-facing capabilities
• Vendor records (cmdb_ci_vendor): Supplier organizations
• Contracts: Maintenance contracts, support agreements
• Service Offerings: CSDM-defined offerings (covered in Part 5)

Air-Gapped and Restricted Systems

• OT/SCADA systems: Industrial control systems for factories, utilities. Cannot have network scanners touching them due to safety risks.
• Classified systems: Government/defense systems physically isolated from corporate networks
• Legacy systems: Old mainframes or proprietary systems that don't respond to modern probes

How to Populate Non-Discoverable CIs

Three primary methods exist for getting non-discoverable CIs into the CMDB. Knowing which method is appropriate for which scenario is exam-tested content.

Method 1 — Manual Entry via the CMDB Form

The most straightforward approach: navigate to the appropriate CMDB table (e.g., cmdb_ci_netgear or cmdb_ci_business_app), click New, fill in fields, save. This is appropriate when:

• Volume is low (a few dozen CIs)
• The CI type is unique or complex (a specific business service with many relationships)
• Initial setup of a brand new CI type with no source data to import from

Limitation: Doesn't scale. For 500 non-discoverable printers, you wouldn't enter each manually.

Method 2 — Import Sets with Spreadsheet/CSV

When you have many non-discoverable CIs already tracked in a spreadsheet, database, or another system — use the Import Set pipeline you learned in Topics 1–4:

1. Export your existing tracking spreadsheet to CSV
2. Define a Data Source pointing to the file or a recurring export
3. Create a Transform Map to map spreadsheet columns to CMDB fields
4. Configure Coalesce on a unique identifier (serial number, asset tag, name)
5. Run the import; Transform Map creates/updates the CMDB records

This is the preferred method when:

• Migrating from a legacy asset management tool or spreadsheet
• Ongoing sync with an external asset database that exports CSV/XML
• Bulk population of physical infrastructure records (hundreds to thousands)

Method 3 — Dedicated SGC or Custom Integration

Some "non-discoverable" CIs actually have a data source — just not a network-scannable one. For example:

• License management tools like Flexera or Snow Software track software licenses. An SGC or custom integration can pull this data into the CMDB.
• Asset management databases (legacy CMDBs, ServiceNow Asset Management module) may have records for physical items. An integration can sync these.
• Building management systems may track power and cooling infrastructure via their own API.

In these cases, treat the external tool as the authoritative source and build an integration (SGC if available, custom Integration Hub flow if not) to pull data in.

CI Classes for Non-Discoverable Items

ServiceNow's CMDB class hierarchy (fully covered in Part 5) has specific tables for different types of CIs. Non-discoverable CIs go into specific classes depending on what they represent.

Common Non-Discoverable CI Classes

Maintaining Non-Discoverable CIs Over Time

The hardest part of non-discoverable CIs isn't creating them — it's keeping them accurate. Unlike discovered CIs which get updated automatically, non-discoverable CIs become stale unless you build explicit processes to update them.

The Staleness Problem

Discovered CIs have a last_discovered field that updates every time a scan runs. When that field is old, you know the CI might have changed. Non-discoverable CIs have no equivalent automatic refresh. A cable CI from 2019 might still say port 12 connects to Server X, even though a technician recabled it in 2022 and never updated the CMDB.

Governance Processes for Maintaining Non-Discoverable CIs

Because automation can't maintain these CIs, you need process-driven governance:

• Change Management integration: Require that any Change Request touching physical infrastructure includes a CMDB update task. When a technician recables a server, the Change Request workflow must include "Update cable CIs in CMDB" as a required step.
• Periodic audit tasks: Create scheduled tasks (quarterly/annually) to audit non-discoverable CIs. A network team audit task: "Verify all cable CIs in Rows 3–5 are current."
• Asset tag integration: If physical items have asset tags, integrate with the Asset Management module. Physical asset audits (barcode scanning) can trigger CMDB updates.
• Business service reviews: Schedule quarterly business service review meetings where application owners confirm that the business application CI still accurately reflects the components.

Using CMDB Health to Track Non-Discoverable CI Staleness

In Part 6, you will learn that ServiceNow's CMDB Health dashboard tracks health KPIs including staleness and completeness. For non-discoverable CIs specifically:

• Define a completeness rule for your non-discoverable CI class that requires specific fields (e.g., cable CI must have both endpoint fields populated)
• Define a staleness rule that flags CIs not updated in more than X days
• Route flagged CIs to a Data Manager task queue for review (Part 6)

Relationships — Why Non-Discoverable CIs Matter for Impact Analysis

A CI record without relationships is nearly useless for impact analysis. Relationships connect CIs together into the dependency map that powers ServiceNow's change impact analysis, availability tracking, and service health views.

When you create a non-discoverable CI, you must also define its relationships to other CIs. These relationships are created in the cmdb_rel_ci table using relationship types defined in the CI Relationship Type table.

Common Relationship Types for Non-Discoverable CIs

Creating Relationships via Import Sets

When bulk-importing non-discoverable CIs, you can also import relationships in the same Transform Map or a separate one. The Transform Map can:

• Look up related CIs by name or IP address using reference field mapping
• Insert rows into cmdb_rel_ci directly to establish relationships
• Use a script field in the Transform Map to programmatically create relationship records

Special Strategies for Air-Gapped and High-Sensitivity Systems

Some non-discoverable CIs aren't just "hard to discover" — they must not be scanned. Industrial control systems, classified networks, and high-security environments require special handling.

OT/SCADA Systems

Operational Technology (OT) systems control physical industrial processes — manufacturing lines, power grids, water treatment, building automation. These systems often run on decades-old software and cannot tolerate the network traffic that a Discovery probe would generate. A port scan against a SCADA controller could disrupt an industrial process.

Strategies for OT in the CMDB:

• Vendor-provided inventory: Ask the OT vendor for a CSV export of their asset inventory. Import via Import Sets.
• Physical audit: Walk the factory floor, record every device. Enter via manual form or bulk Import Set.
• Passive Discovery: Some Discovery tools support a read-only, non-invasive mode. ServiceNow's Discovery can use passive network traffic analysis rather than active probing (check with your Discovery team).
• Network segmentation documentation: If OT systems are on isolated network segments, document the segment as a CI and relate OT devices to it.

Air-Gapped Classification Networks

Government and defense environments often have physically isolated networks for classified information. These cannot be touched by any tool connected to a corporate network.

• Maintain a separate, manual CMDB for classified assets using a dedicated ServiceNow instance (not connected to the corporate instance)
• Or maintain classified asset records in a separate, air-gapped system and periodically export a sanitized list to the corporate CMDB (without sensitive attributes)
• Define relationship stubs: "CI: Classified System Group (details restricted)" as a placeholder CI linked to the systems that interface with it

Practice Questions

4 questions · Select an answer to see the explanation immediately.