CMDB Data Manager is ServiceNow’s policy-driven framework for managing CI lifecycle at scale. Instead of relying on ad hoc scripts or manual cleanup, teams can define policies that identify target CIs and create governed actions for retirement, archival, deletion, attestation, certification, and related lifecycle work.
For CIS-DF, the exam emphasis is scenario-based: choose the policy feature that matches the business goal, understand prerequisites such as retirement definitions, and know how approvals, exclusions, ownership, schedules, and dependent CIs affect safe execution.
Use policies to make lifecycle management repeatable
Large CMDBs change too quickly for one-time cleanup projects. Cloud resources disappear, servers are retired, applications move, ownership changes, and stale records accumulate. Data Manager policies convert lifecycle rules into a repeatable operating process.
A policy should encode an organizational decision that would otherwise be applied manually. The goal is consistency and traceability, not automation for its own sake.
Use Retire when the CI should remain in the CMDB but no longer be active
A Retire policy marks a CI as retired according to the class’s retirement definition. The record remains available for history and can continue to participate in some platform processes, but its lifecycle state reflects that it is no longer in normal use.
Retirement is often the first step before archive or delete. It provides a controlled transition rather than immediately removing the record.
Use Archive when the CI should leave active views but remain recoverable for a period
Archiving moves a CI out of its active table into an archive context for temporary retention. This can reduce active CMDB volume while preserving the ability to restore data during the retention period.
Archive is appropriate when the organization no longer needs the CI in active operations but still has a reason to retain it temporarily. The retention and restoration rules should be defined before broad use.
Use Delete when the organization is ready to remove the CI
A Delete policy permanently removes targeted CIs according to the configured process. Because deletion can affect relationships and dependent records, it should be governed more carefully than a simple cleanup script.
Delete criteria should be specific, tested, and aligned with retention policy. Teams should avoid deleting merely because a CI is old; age is one signal, not proof that the record has no business or operational value.
Use Attestation when existence or data needs confirmation
Attestation creates a controlled process for responsible users or teams to confirm that CIs still exist or that their information is valid. It is useful for contextual data that automated discovery cannot fully verify.
Attestation works best when the target population is meaningful and the assignee has enough knowledge to answer. Sending broad, repetitive tasks to users who cannot validate the records creates noise instead of quality.
Use certification or validation controls for required data states
Organizations may need to certify that attributes or configurations meet defined expectations. Data-quality and compliance features can turn those expectations into repeatable checks and remediation tasks.
In exam scenarios, read the required outcome carefully. Verifying a CI’s existence is different from enforcing a lifecycle action or checking whether attributes meet a desired state.
Retirement definitions are prerequisites for key lifecycle policies
Retire, Archive, and Delete policies depend on retirement definitions for their targeted classes. A retirement definition describes how a class is considered retired and allows Data Manager to handle lifecycle consistently.
If a required definition is missing, the policy cannot safely apply the intended lifecycle action. This is a good example of ServiceNow preferring governed class-specific behavior over generic bulk modification.
Target conditions should be narrow and testable
Policies need clear criteria for the CIs they affect. A useful condition might combine class, location, lifecycle state, ownership, discovery age, or another attribute that directly represents the business rule.
Before scheduling a large policy, validate the target set. A filter that is technically valid but too broad can create a large remediation event, so administrators should confirm what the policy will touch.
Use schedules and approvals to control execution
Policies can run on schedules so lifecycle management becomes continuous. Approval settings determine whether generated tasks proceed automatically or require human review.
High-impact actions often deserve staged adoption: start with a narrow population, require approval, inspect results, and only then expand automation. Mature governance can reduce manual review later when confidence is high.
Use exclusions for exceptions that should not follow the general policy
Some CIs need to be excluded even when they match the normal targeting rule. Exclusion lists provide a governed way to preserve exceptions without weakening the policy for everyone else.
Exceptions should have owners and reasons. An exclusion list that grows without review can become a hidden second policy and undermine lifecycle consistency.
Consider dependent CIs and relationship impact
Retiring, archiving, or deleting a CI can affect dependent records and relationships. Data Manager includes controls for dependent CI handling so lifecycle changes do not leave the CMDB in a broken state.
Before enabling cascade behavior, understand which relationships express real dependency. Incorrect relationship data can turn a reasonable lifecycle policy into an unintended chain of actions.
Monitor policy outcomes and refine the process
After a policy runs, review task volume, approvals, failures, exclusions, and the effect on CMDB Health. If users reject many tasks or administrators repeatedly intervene, the targeting, ownership, or lifecycle definition may need adjustment.
In CIS-DF, Data Manager policies should be studied as part of CMDB lifecycle governance. A policy can automate a routine, but administrators still need trustworthy ownership, appropriate scope, reviewable evidence and a way to handle exceptions.
Exam focus: match the desired lifecycle outcome to the policy
Retire when the record should remain but become inactive. Archive when it should leave active use but be retained temporarily. Delete when permanent removal is appropriate. Use attestation when ownership or existence must be confirmed. Check prerequisites, target criteria, approvals, exclusions, and dependencies before choosing automation.
IT service management certifications cover larger service workflows, while CIS-DF examines how ServiceNow implements the data rules those workflows rely on. Knowing when a record should be reviewed, retained or retired is as important as knowing how to configure the scheduled process.
Design policy names and descriptions for operators
A policy should clearly state what it targets and why. Names such as ‘Retire inactive production Windows servers after approved lifecycle threshold’ are more useful than generic labels such as ‘Cleanup policy 3.’
Clear descriptions help approvers understand the business intent and reduce the risk that future administrators change or duplicate policies without knowing their purpose.
Test policy scope before scheduling it
Before enabling recurring execution, preview or otherwise validate the target set with representative data. Check both expected matches and near-misses that should be excluded.
Boundary testing is especially important for date and status filters. A small logic error can target far more CIs than intended when the policy runs across a large class.
Review task assignment and escalation
Policies often generate work that needs an owner. Managed-by groups, administrators, or designated approvers should be able to resolve the tasks. If ownership fields are missing, Data Manager can push work to administrators and create avoidable bottlenecks.
Good lifecycle governance therefore depends on accurate ownership data as well as technically correct policy conditions.
Use retention policy to distinguish archive from delete
Archive is useful when the business may need to restore or review a CI during a defined retention period. Delete is appropriate only when that retention need has ended and removal is authorized.
This decision should align with operational, legal, and audit requirements. Data Manager implements the process, but governance determines the policy.
Revisit policies as the CMDB changes
A policy that was correct when created may become outdated after class redesign, new discovery sources, CSDM changes, or different retention requirements. Teams should review active policies periodically and after major platform changes.
Policy review should include target counts, exclusions, rejection rates, and downstream impact. Lifecycle automation stays safe only when the rules remain aligned with the environment.
Use staged rollouts for destructive policy types
Retire, archive, and especially delete policies should be introduced gradually. Start with a narrow class or environment, review generated tasks, verify dependent-CI behavior, and compare the resulting health and operational impact before expanding scope.
A staged rollout catches incorrect filters and ownership gaps when the affected population is still small. It also gives approvers evidence that the automation behaves as intended.
Design for exceptions without abandoning the standard
Every organization has exceptions, but exceptions should not force teams back to manual lifecycle management. Use exclusion mechanisms or narrowly scoped alternate policies so the standard process remains intact for the majority of CIs.
Review exceptions periodically. A CI that was excluded during a migration or special project may no longer need special treatment months later.
Treat Data Manager as governance automation
Data Manager is most effective when policies implement decisions that the organization has already agreed on: when a class should be retired, how long records should be retained, who can approve deletion, and which CIs are exceptions. The tool automates governance; it does not replace the need to define governance.
When those decisions are explicit, policy behavior becomes easier to explain, audit, and maintain.