Reconciling Discovery Observations Against a CMDB Before Audit
Northbridge Health runs 14 hospitals and a central IT shared service. Its discovery tool performs authenticated scans weekly and unauthenticated network sweeps daily, dropping results into a staging database. The CMDB holds 3,140 configuration items, but the latest discovery run returned 4,380 unique devices across the same IP ranges. Investigators found: 610 devices appear in discovery only; 240 CIs have not been seen in 90 days; 310 records differ only by hostname suffix (short name versus FQDN); 190 IP addresses map to two different CIs because a DHCP scope was re-numbered in March. Clinical engineering separately maintains a spreadsheet of 1,100 medical devices on static addresses, and 380 of those never appear in discovery because a segmentation firewall blocks their ports. The CMDB manager wants to import every discovery record and "let the tool deduplicate" before next month's audit.
1. Assess the proposal to import all discovery records and let the tool deduplicate. What reconciliation logic would you apply before the audit?
Read the worked answer
Import-everything fails because it treats discovery observations (IP, MAC, hostname, timestamp) as assets. One laptop seen with three hostnames becomes three CIs, and the population you present to the auditor is inflated and indefensible.
The logic to apply first:
- Identity resolution, deterministic before probabilistic. Key on serial number, BIOS/UUID, or cloud resource ID where present. Fall back to MAC address plus normalised hostname within a last-seen window. Never use IP address as an identifier - the March re-scope proves IP is a mutable attribute, so the 190 dual-mapped addresses should be attached as time-bound attributes, not new CIs.
- Normalise, don't hand-merge. The 310 suffix variants are a transform rule (strip domain suffix, lowercase) applied in the ETL layer.
- Expect legitimate one-to-many. Virtual guests and their hypervisor host, printers, UPS units and IP phones are real devices but not all belong in the same CI class; route them to the right class rather than deleting them.
- Quarantine. New records land in a "discovered / unverified" state with an owner and a 30-day ageing clock. Nothing enters a production CI class without an owner.
Realistic outcome: 4,380 observations resolve to roughly 3,700–3,900 distinct devices. The audit question is "can you prove the population", not "is the number big".
2. How should the 240 unseen CIs and the 380 firewall-blocked clinical devices be handled? Should they be retired?
Read the worked answer
They have opposite root causes and must not share a rule.
The 240 unseen CIs may be genuinely retired, or may be a discovery coverage failure - expired scan credentials, a decommissioned subnet, an uninstalled agent. Before any retirement, corroborate against independent evidence: DHCP leases, DNS records, AD computer accounts, warranty entitlements, last logon, and open tickets. Retire only when several independent sources agree the asset is gone; otherwise move to "unverified / pending retirement" with the CI owner's sign-off and a 30-day hold. Retiring on the strength of one scan is how you lose servers.
The 380 clinical devices are present and operating. They are a coverage gap, not a retirement candidate. Do not mark them missing - an audit that finds 380 "missing" infusion pumps is worse than the original problem. Instead:
- Declare the clinical engineering register an authoritative source for that asset class, with a documented interface and its own reconciliation cadence.
- Record the blocked ports as a known, accepted control gap with an owner and a review date - segmentation is deliberate, so absence from discovery is expected.
- Report discovery coverage explicitly: "83% of the estate is in scope of automated discovery; the remaining 17% is covered by an authoritative third-party feed." That is an honest, auditable statement.
Never let two registers both claim to be the master for the same devices.
3. What governance changes would stop this recurring after the audit?
Read the worked answer
Fix the system, not the spreadsheet.
- Authoritative source matrix. For each CI class, name one system of record and the direction data flows. Medical devices: clinical engineering. End-user compute: the endpoint tool. Servers: discovery. Ambiguity here is what produced the 310 duplicates.
- Identity rules as written policy. Codify which attributes are identifiers and which are mutable, so the DHCP re-scope cannot silently create CIs again.
- Change integration. A DHCP re-scope, subnet build, or new firewall segmentation rule should raise a CMDB impact task automatically. The March re-numbering was a change-management failure surfacing as a data-quality problem.
- Reconciliation KPIs with thresholds and owners: match rate between discovery and CMDB, count and age of unmatched observations, count of CIs not seen in 60/90 days, percentage of estate in discovery scope. Report weekly to the CMDB manager and monthly to the service owners.
- A standing data-quality forum with clinical engineering, network, and service management, empowered to approve merges and retirements.
Track one outcome metric - unmatched records older than 30 days - because it is the leading indicator of every problem in this estate.