ServiceNow CIS-DF (Data Foundations: CMDB and CSDM) Study Guide

Certified Implementation Specialist, Data Foundations. Organized by the five official exam domains (blueprint KB0012913, updated November 2025) and checked against the Zurich product documentation and the CSDM 5 white paper (October 2026 audit). Original content mapped to the public blueprint; not affiliated with or endorsed by ServiceNow.

The exam is 75 questions in 90 minutes: multiple choice, multiple select, drag and drop matching, and scenario items. There is no partial credit on multiple select or drag and drop, and the cut score is not published. Weight your study toward Govern (35%), then Insight (20%), Ingest (19%), Configuration (15%) and CSDM Fundamentals (11%).

Big picture: CIS-DF is about a CMDB people can trust. Data comes in through the IRE (identification and reconciliation), is shaped by CSDM, is measured by CMDB Health (Correctness, Completeness, Compliance), is kept clean with CMDB Data Manager and de-duplication, and pays off through Insight tools such as CMDB Query Builder, Intelligent Search and Unified Map.

Domain 3: Govern (35%)

The heaviest domain, so study it first.

CMDB Health: three KPIs, six metrics

KPI	Metrics	What they measure
Correctness	Orphan, Staleness, Duplicate	Orphan: CIs that meet the class's orphan rule (missing required attributes and/or missing relationships; one orphan rule per class). Staleness: CIs not updated within the staleness rule's Effective Duration (base rule on Configuration Item: 60 days). Duplicate: CIs found by identification rules; only independent CIs are evaluated, and a set counts as total CIs minus one.
Completeness	Required, Recommended	Required: CIs missing mandatory fields. Recommended: CIs missing fields marked recommended. Default metric weights inside the KPI are 60% Required and 40% Recommended.
Compliance	Audit	CIs that fail CMDB audits. Audits must be activated before Compliance shows results.

Overall score: in Zurich the overall CMDB Health score is, by default, a simple average of the three KPI scores. Custom KPI and metric weights (CMDB Health Metric Preferences) only apply when an admin with sn_cmdb_admin turns on Use legacy calculation methods, the pre-Washington DC method.
Relationship health is separate. Duplicate, orphan and stale relationships, plus relations that break suggested relationship, containment or hosting rules, are non-configurable metrics viewed on the Relationship Health Dashboard. They are not one of the three KPIs.
Where you configure it: class-level health settings live in CI Class Manager, in the class's Health section (for example Correctness, then the Staleness Rule or Orphan Rule tab).
It is off by default: the CMDB Health Dashboard jobs are disabled in the base system, so no health data appears until they are enabled.
The CMDB Health Dashboard shows the overall score and each KPI, with drill-down to failing CIs. It is the place to validate data quality and compliance against your KPIs and critical success factors.

CMDB Data Manager

A policy-driven framework for bulk CI life cycle operations, administered from CMDB Workspace. Policies apply to classes that extend Configuration Item [cmdb_ci]. Six policy types:

Policy	Use it to
Retire	Mark CIs retired while they stay visible in lists and in CMDB Health
Archive	Move CIs to an archive table for a retention period; they can be restored during that period
Delete	Remove CIs permanently, with no restore
Attestation	Create tasks so the people who manage CIs confirm they still exist (useful for manually maintained CIs)
Certification	Certify that specific attributes hold specific values
Delete CMDB Related Entry	Clean up stale records in related tables that reference a CI (for example serial numbers)

Targeting: a policy picks its CIs with a data filter: a table plus filter conditions (and related list conditions), optionally narrowed by an exclusion list. Principal classes are not the Data Manager scoping mechanism.
Prerequisites: Retire, Archive and Delete policies need an active retirement definition for each targeted class; creating the policy fails without one. Attestation does not need one.
Approvals and tasks go to the CI's Managed by group; if it is empty, approvals go to the administrator.
CSDM life cycle order: CIs that are no longer needed are retired first, then archived or deleted according to business needs.
Scenario tip: match the goal to the policy. "Remove but must be restorable" is Archive. "Gone for good" is Delete. "Confirm the CI is still real" is Attestation. "Confirm an attribute value" is Certification.

Principal classes

A designation set per class in CI Class Manager (Class Info, Basic Info, Principal Class) by sn_cmdb_admin or itil_admin. It is not inherited by child classes, and the base system has no principal classes.
Principal classes are the classes prioritized for tracking, health, certification and life cycle work. The Principal Class filter limits CI lists and dashboards to them, and a task property (com.snc.task.principal_class_filter) limits CI lookups on incident, problem and change records to principal classes.

Duplicates and de-duplication

How duplicates appear: the same real item arrives from several sources with weak or inconsistent identifier data (for example one source sends only a serial number and another only name and IP), legacy imports that bypassed the IRE, or poorly designed identification rules.
What the IRE does: when identification matches more than one CI, the IRE groups the set into a de-duplication task. With the default glide.identification_engine.skip_duplicates = true and fewer duplicates than the threshold (default 5), it updates the oldest CI (the main CI) and sets duplicate_of on the others. With skip_duplicates = false, matching fails with an error and no CI is updated.
Remediating one task: the Duplicate CI Remediator wizard. Pick the main CI, then either Remediate Manually (choose values attribute by attribute) or Use Main CI (keep main CI values, merge relationships and default related items). The recommended action for the other CIs is to set attributes to custom values (for example mark them retired) so they are kept but excluded from future tasks; deleting them is the alternative.
Remediating many tasks: de-duplication templates run from the CMDB Workspace De-duplication Dashboard. A template can also be applied to a single task.

Life cycle CI attributes

CSDM standardizes life cycle on two fields: Life Cycle Stage (the broad phase, such as Operational) and Life Cycle Stage Status (the detail within it, such as In Use).
Life Cycle Mapping rules map legacy values (Install Status, Operational Status, Hardware Status, asset State) per table to the best-fit stage and status pair; when several rules match, the highest priority rule (lowest number) wins. Legacy fields are not deleted.

Governance roles and operating the CMDB

Configuration Manager / CMDB process owner: owns the CMDB process, policies and overall health.
CI class owner: accountable for the data quality and standards of specific classes.
Data steward: works the data day to day (remediation tasks, attestations, fixes) under the agreed standards.
Platform owner / architect: owns the data model design and standards.
Operationalizing the CMDB means continuous governance rather than a one-time load: health jobs running, dashboards reviewed, de-duplication and attestation tasks worked, audits active, and Data Manager policies on a schedule.
CMDB Workspace is the role-based home for this work: CMDB Health, Data Manager administration and tasks, de-duplication, CMDB 360 and saved queries, Intelligent Search and the Data Foundations dashboards.

Domain 4: Insight (20%)

Insight is about getting answers and value out of CMDB data.

Business value: the CMDB connects assets, services, users and cost in one system of record. Products use it for change impact and risk, incident and alert impact (Event Management binds alerts to CIs and calculates service impact), Vulnerability Response (impacted services for a vulnerable item) and asset management. Measure value by consumption, for example the share of incidents and changes that reference a CI or service, not by CI counts.
Intelligent Search (Natural Language Query): type a plain-language question in CMDB Workspace and get CMDB results without building filters. When terms are ambiguous a Refine your query step lets you pick the intended tables; a multi-table result can be opened in Query Builder to keep refining.
CMDB Query Builder and saved queries: build graphical, multi-class relationship queries by dragging classes onto a canvas and connecting them. Connection options include relationship levels (first level or up to second level), specific relationship types, No Relationships (to find CIs that are not connected) and And/Or between branches. Saved queries can be scheduled, turned into reports, and exported as update sets to other instances. Load All Results before exporting a large result set.
CMDB 360 queries: in CMDB Workspace, query multisource data with Get Records, Find Gap (CIs reported by one source but not another) and Compare Attribute Values (values that differ across sources).
Unified Map: the current dependency visualization. It combines capabilities of Dependency Views and Service Mapping maps. Key components: the map canvas with a Levels control, a side panel (Overview, Attributes, Related items such as open incidents, problems and changes, Service instances), a timeline for correlating changes and incidents with an outage, and a map editor that can add CIs and update relationships in the CMDB.
CMDB and CSDM Data Foundations Dashboards (free Store app): the CMDB Data Foundations dashboard groups data-quality metrics into tabs (Best Practices, Customizations, Data Management Practices, ITSM Processes), gives each metric a priority from 1 (Critical) to 5 (Low) based on its weight and score, and links each metric to a remediation playbook. The CSDM Data Foundations dashboard tracks CSDM maturity by stage (Foundation, Crawl, Walk, Run, Fly). Data appears after the metric collection job has run.
Playbooks: remediation playbooks are knowledge articles on Now Support, reached from each dashboard metric, that explain the issue and how to bring CIs into compliance. Use them when the dashboard shows a problem and you need the fix, not just the failing CIs.

Domain 2: Ingest (19%)

Ingest is about getting data in cleanly, through the IRE, without creating technical debt.

Choosing an ingestion method (a common scenario):

Discovery: agentless, scheduled discovery through MID Servers; also creates many infrastructure relationships.
Service Mapping: builds application service maps and their relationships top down.
Service Graph Connectors (SGCs): the preferred, certified way to bring third-party data (for example Microsoft SCCM, Intune, cloud and security tools) into the CMDB. They are built on IntegrationHub ETL and send data through the IRE. Install and monitor them from SGC Central and the Integration Commons dashboard.
Agent Client Collector: agent-based collection from endpoints.
IntegrationHub ETL / Robust Transform Engine: build your own IRE-aligned integration when no connector exists.
Import sets and manual entry: for non-discoverable CIs and attributes (business applications, manually maintained service instances). Apply the IRE to import sets so they do not create duplicates.

Minimize technical debt: prefer certified connectors and IRE-based integrations over custom scripts that write straight into CMDB tables. Connectors still need normal upgrade work: customizations of legacy integrations (such as the old SCCM plugin's transform maps) do not migrate automatically and must be rebuilt.

Relationships are populated automatically (Discovery, Service Mapping, connectors sending relations in the IRE payload) or manually (relationship editor, Unified Map editor). Dependent relationships (hosting and containment rules) let the IRE identify dependent CIs in context.

Non-discoverable CIs: load them by import or manual entry, assign an owner, and keep them current with Data Manager attestation policies. Remember that Foundation records such as companies, locations, buildings and contracts are referential data, not CIs.

Security and regulatory compliance against CSDM objects: the CSDM Information Object, referenced by the business application, describes the data an application uses (for example PII, PCI or HIPAA data and its sensitivity), which lets audits be scoped by data type.

Asset and CI alignment:

An asset (alm_asset, financial and contractual view) and a CI (cmdb_ci, operational view) are two separate records kept in sync by two business rules: Update CI fields on change (on alm_asset) and Update Asset fields on change (on cmdb_ci).
Sync happens only when the asset and the CI reference each other.
State mapping is not one-to-one. For hardware CIs, the asset State and Substate map to the CI Hardware Status and Substatus. For non-hardware CIs, the asset State maps to Install Status. Install Status and Hardware Status are independent fields.

Domain 1: Configuration (15%)

CI Class Manager

The single place to manage CMDB classes: the class hierarchy (classes that extend cmdb_ci), Basic Info (display name, description, icon; the table name cannot be changed), attributes, identification and reconciliation rules, dependent relationships, health settings and principal class designation. A child class can be added only under a class marked extendable.

IRE: identification

Identification rules decide whether an incoming payload matches an existing CI. A rule has identifier entries, tried in priority order, each with criterion attributes that must all have values (unless null is allowed).
Prefer independent rules (the class carries enough attributes of its own). Dependent rules identify a CI in the context of another CI through hosting or containment rules; keep dependency to one level, two at most.
When a payload carries a known source name and source native key, the IRE can identify the CI from them.
Identification inclusion rules limit which CIs of a class are match candidates (for example only operational CIs).
IRE data source rules stop a specific source from inserting new CIs for a class while still allowing updates.
With the enhanced API, items that cannot be identified yet (for example a disk whose computer has not arrived) are held as partial payloads and merged when a matching payload arrives.
Identification Simulation lets you test how the IRE would process a payload without changing data.

IRE: reconciliation

Static reconciliation rules say which sources may update which attributes and in what priority (a smaller number is a higher priority). A rule for a specific attribute takes precedence over an Apply to all attributes rule. Sources without a rule get the lowest priority.
A lower-priority source can still write when it is the first to update the CI, or when the authoritative source has gone stale under a data refresh rule (Effective Duration per source and class).
Dynamic reconciliation rules choose a value from CMDB 360 data (for example the most reported or largest value) and require CMDB 360.

CMDB 360 / Multisource CMDB

Enabled by activating the ITOM Discovery License plugin and turning on the CMDB 360 property (off by default).
Stores what each source reported for each CI, including values that were not selected, so you can compare sources, see which source set each attribute, revert a bad source's updates and recompute values. Classes can be excluded.
Use it when several sources report on the same CIs and you need to see and reconcile their differences.

Domain 5: CSDM Fundamentals (11%)

Why CSDM: a prescriptive, shared data model that ServiceNow products are built to read and write. Following it means less custom model to maintain (less technical debt), more out-of-box functionality, a common language across teams, and service-aware impact and reporting. CSDM itself ships no reports; it defines where data belongs.

CSDM 5 domains (seven):

Foundation: referential data such as companies, departments, locations, users, groups, product models and contracts. Most of it is not CIs (a CI points to its product model through the Model ID field). Business Process is the exception: a manually maintained CI in Foundation.
Ideation & Strategy (new in CSDM 5): product ideas, strategic priorities, goals and planning items before an investment decision.
Design & Planning: enterprise architecture records such as Business Capability, Business Application and Information Object. Business Applications are portfolio records, not operational CIs.
Build & Integration: development data such as SDLC Components (APIs, microservices, UI modules).
Service Delivery: operational, provider-side records: Service Instance (the CSDM 5 label for cmdb_ci_service_auto, formerly Application Service) and new Service Instance classes (Connection, Data, Facility, Network, Operational Process), Technology Management Service (formerly Technical Service) and its offerings, and Dynamic CI Group (cmdb_ci_query_based_service).
Service Consumption: what consumers see and request: Business Service, Business Service Offering, service portfolios and request catalogs.
Manage Portfolio: a layer that spans the lifecycle domains (for example a service owner overseeing applications, instances and services).

Old names you may still see: before CSDM 5 the domains were Foundation, Design, Build, Manage Technical Services, Sell/Consume and Manage Portfolio (six). CSDM 5 added Ideation & Strategy and renamed the rest.

Mapping scenarios (how to place things):

A customer-facing service with tiers: Business Service with Business Service Offerings (Service Consumption).
One application deployed in several environments or regions: one Business Application, one Application Service / Service Instance per deployment, related with Uses::Used By (CSDM 5; earlier versions used Consumes::Consumed by, which Enterprise Architecture Workspace users keep).
Different support or approval groups for production and non-production: Technology Management Service Offerings per environment.
A large, changing set of servers under one offering: a Dynamic CI Group related to the offering.
Operational CIs for incident, problem and change impact: Business Service, Technology Management Service and offerings, Service Instances, infrastructure CIs. Not Business Applications, Business Capabilities or SDLC Components.

Approach to adopting CSDM: do not implement everything at once. Prepare Foundation data, then progress through Crawl (Business Application, Application Service, Application, servers: quick ITSM wins), Walk (Technology Management Services, offerings, Dynamic CI Groups), Run (Business Service Portfolio, Business Services and offerings) and Fly (Business Capability, Information Object and the wider portfolio), each stage building on the last.

Fast-recall cheat list

CMDB Health: 3 KPIs (Correctness, Completeness, Compliance), 6 metrics (Orphan, Staleness, Duplicate; Required, Recommended; Audit). Overall score = simple average of the KPIs by default; weights only with legacy calculation. Relationship health is separate.
Staleness default: 60 days. Orphan: one rule per class. Duplicates: independent CIs only. Health jobs are off by default; audits must be on for Compliance.
Data Manager: Retire, Archive (restorable), Delete (permanent), Attestation, Certification, Delete CMDB Related Entry. Data filter targets CIs. Retire, Archive and Delete need a retirement definition.
Principal class: set per class in CI Class Manager, not inherited, none in base system.
IRE duplicates (default): update the oldest CI, set duplicate_of on the rest, open a de-duplication task. One task: Duplicate CI Remediator. Many tasks: de-duplication templates.
Reconciliation: smaller number wins; attribute-specific beats all attributes; data refresh rules let a lower source take over a stale attribute; dynamic rules need CMDB 360.
Asset and CI: two records, sync only when they reference each other; hardware asset State maps to Hardware Status, non-hardware to Install Status.
Insight: Query Builder (saved, scheduled, reports, update sets), Intelligent Search, CMDB 360 queries (Get Records, Find Gap, Compare Attribute Values), Unified Map, Data Foundations dashboards with playbooks.
CSDM 5: seven domains; Foundation is referential; Service Instance = cmdb_ci_service_auto; Technical Service is now Technology Management Service; adopt Foundation, Crawl, Walk, Run, Fly.