Section 3.4: Non-Discoverable CIs, Manual Data, and Compliance Identifiers

Non-Discoverable CIs, Manual Data, and Compliance Identifiers

1. Why Discovery Is Not Enough

Discovery and Service Graph Connectors populate the CMDB for infrastructure they can reach over the network. But a healthy, service-aware CMDB also contains CIs that are inherently non-discoverable:

• Business Applications and Business Services (conceptual, not network endpoints)
• Contracts, licenses, and vendors referenced from CIs
• Facilities / locations and non-networked hardware
• Attributes no scanner can read: business owner, environment, data-classification, compliance scope

The CIS-DF Ingest domain (19%) explicitly tests how to populate and maintain non-discoverable/manual CIs or non-discoverable attributes. The governing rule is unchanged: all writes still go through the IRE, even manual ones, so identification and reconciliation rules protect against duplicates and unauthorized overwrites.

2. Loading Manual and Non-Discoverable Data

There are three sanctioned paths, in order of preference:

The classic anti-pattern is a transform map that inserts straight into cmdb_ci_* tables. That bypasses the IRE, creating duplicates and untracked source data — exactly what governance is meant to prevent. On the exam, any option that mentions "disable the IRE for speed" or "write directly to the table" is a distractor; the IRE is never bypassed, no matter how the data arrives.

When an Import Set is the right choice, the transform routes rows through the CMDB API's identifyAndReconcile call rather than a plain field-to-field insert. That single design decision buys three things: identification rules match incoming rows against existing CIs (so a re-run updates instead of duplicating), reconciliation rules decide which source wins per attribute when several systems disagree, and every write is attributed to a discovery/data source so multisource CMDB (CMDB 360) can later show where a value came from. Manual entry through a form or CMDB Workspace gets the same protection for free, because the platform's business rules push the save through the IRE automatically.

3. Ownership and Staleness for Manual Data

Because Discovery never revisits manual CIs, their sys_updated_on (and therefore health staleness) will keep aging. Two safeguards are expected knowledge:

• Assign an owner (CI Class Owner or Data Steward) responsible for periodic review.
• Tune the staleness rule for classes that are legitimately static (a contract does not change weekly), or use attestation through CMDB Data Manager so an owner formally re-verifies the record, resetting its currency.

The distinction the exam wants is between fixing the metric and fixing the data. Blindly widening every staleness window hides real problems; the disciplined answer is to lengthen the window only for classes that genuinely change slowly, and to use attestation campaigns so a human owner confirms a record is still accurate. A successful attestation resets currency legitimately, giving you an audit trail of who verified the record and when — which is exactly the evidence an auditor expects for manually maintained data that no scanner can corroborate.

4. Security and Regulatory Compliance Identifiers

A core Ingest objective is tracking security and regulatory compliance identifiers against CSDM objects. Rather than storing "in PCI scope" as free text, the CMDB should model compliance as structured data on the right CSDM object, typically the Business Application or Application Service:

• Boolean or choice attributes such as PCI, SOX, or HIPAA scope flags.
• Data-classification attributes (public / internal / confidential / restricted).
• Relationships to control or policy records where a full governance module is used.

Modeling compliance this way lets audits, reporting, and impact analysis answer questions like "Which application services are in PCI scope and depend on this database?" — impossible if the identifier lives only in notes.

Why the CSDM object rather than the infrastructure CI? Because compliance scope is a business fact that flows from a service down to whatever supports it. Tagging PCI on a single server is fragile — the server can be re-platformed, replaced, or added to. Tag it on the Application Service or Business Application, and impact analysis can then walk the relationships to enumerate every dependent infrastructure CI automatically. The identifier travels with the service, which is exactly the durability an audit requires. This also keeps the compliance signal in the same layer of the CSDM model where enterprise architects and auditors already look, rather than scattering it across thousands of discovered endpoints.

A practical pattern: pair the scope flag with a data-classification attribute and, where a governance product is in play, a relationship to a control or policy record. That combination supports the three questions auditors actually ask — what is in scope, how sensitive is it, and which control covers it — all answerable by query rather than by interview.

5. Asset and CI Alignment

The blueprint calls out Identify how Asset and CI align. Assets (alm_asset and its subclasses) and CIs (cmdb_ci) are separate but linked records:

• The Asset holds commercial and lifecycle data — cost, purchase order, warranty, assigned user, substate.
• The CI holds operational and technical data — IP, OS, relationships, discovery source.
• A sync relationship keeps a defined set of fields consistent: updating the Asset State synchronizes Install Status (and, for hardware, Hardware Status) on the CI, and vice versa.

This is one of the blueprint's published sample questions: "A State field is updated on an Asset record. Which fields are automatically synchronized on the associated CI record?" — the answer is Install Status and Hardware Status (choose two). Watch the distractors: Operational Status and Asset Tag are not part of the sync. Operational Status reflects whether a CI is currently up or down and is driven by events/monitoring, not the asset lifecycle; Asset Tag is an asset-side label with no CI counterpart in the sync.

The reason for two records is separation of concerns: finance and procurement own the commercial view (what it cost, who it's assigned to, when the warranty expires), while operations owns the technical view (how it's configured and what depends on it). The sync relationship is the bridge that keeps the lifecycle status consistent across both without merging the data into one bloated table.

A reliable exam signal: when a scenario mixes financial/ownership facts with operational/technical facts, remember they live on two records joined by the sync relationship — not on a single CMDB row.

6. Quick Reference