CMDB best practices boil down to verifiable controls, each with an owner, evidence, and frequency, that keep CMDB data reliable before, during, and after implementation. This governance checklist organizes these controls into four blocks for ServiceNow, based on CSDM and native data health, certification, and lifecycle tools.
CMDB best practices: what a governance checklist should contain.
A CMDB loses operational trust due to a lack of routine, not a lack of technology. Data enters through Discovery, imports from third-party tools, or manual editing. Without owners and recurring checks, duplicates, outdated records, and blank assignees accumulate and begin to distort impact analysis, incident routing, and automations.
Therefore, each item on the checklist below answers three questions: who is responsible for the control, what evidence proves that it was carried out, and how often is it reviewed? The frequencies are starting suggestions and should be adjusted to the criticality of the services and the size of the team.
This article complements two others on the blog. The guide to Implementing CMDB in ServiceNow with CSDM explains the model's design, and the article about Healthy CMDB, Success Advisor, and Dynamic IRE It details the measurement of quality. Here, the focus is on the governance routine that underpins both.
Block 1: Before implementing, define scope, model, and responsibilities.
Good CMDB practices begin before the first data load. At this stage, the checklist ensures that the CMDB is created linked to a business outcome, a standardized data model, and people with defined responsibilities.
| Control item | Owner | Evidence | Suggested frequency |
|---|---|---|---|
| Business outcomes and CMDB use cases defined | Owner of the process | Scope document approved | Annually or with each relevant change of scope. |
| Main classes and prioritized critical services | Configuration Manager | List of classes and services in scope | Semiannual |
| Model aligned with CSDM 5: where each Business Application, Application Service and Business Service lives | Data architect | Approved domain map | With each new class or service |
| Named roles: Process owner, Configuration Manager, CMDB administrator, and class owners. | Owner of the process | RACI matrix published | Annual |
| Population sources and attribute precedence defined | Configuration Manager and administrator | Matrix of sources by attribute | With each new integration |
| Adopted lifecycle standard, with Lifecycle Stage and Lifecycle Status. | CMDB Administrator | Fields and default values configured. | During implementation and with each upgrade. |
The 4MATT CMDB process guide recommends populating classes in phases, following a crawl, walk, and run scheme. The first phase covers the basic data (companies, users, locations, support groups) and the CIs needed for initial ITSM processes, such as servers, network equipment, and applications. Discovery of databases, storage, and technical services comes next, and the discovery of software and cloud environments is left for the final phase. This order avoids a bulky and unusable CMDB.
In small organizations, the CMDB administrator and the CI analyst may be the same person. However, responsibility for the process should lie with the process owner and the Configuration Manager, who define the strategy, auditing, and verification requirements.
Block 2: During implementation, control data entry.
During the implementation phase, CMDB best practices focus on preventing bad data from entering the repository. The central mechanism is the Identification and Reconciliation Engine (IRE), which decides which record corresponds to which CI and which source prevails for each attribute. IRE technical reference It describes how rules are defined by class.
| Control item | Owner | Evidence | Suggested frequency |
|---|---|---|---|
| Discovery coverage and documented sources by class. | CMDB Administrator | Coverage report | Monthly during implementation |
| Class-revised identification and reconciliation rules | Administrator and Configuration Manager | Rules documented and tested under real load. | With each new source |
| Higher quality fonts protected against overwriting by lower quality fonts. | CMDB Administrator | Review of reconciliation rules | With each new source |
| The "Managed by group" field is configured in the main classes. | CMDB Administrator | No main class without a responsible group. | Quarterly |
| Custom attributes under control: Success Advisor expects fewer than 10 per main class. | Data architect | List of custom attributes by class | Quarterly |
| New or modified Discovery CIs checked against an authorized change | Configuration Manager | Record linked to the change. | Continuous |
Two points deserve attention. The first is data ownership: "Managed by group" is what allows incidents, changes, and requests to be routed to the correct team, and its absence is one of the findings that the Success Advisor evaluates by class. The second is the data source: to understand what feeds the IRE, see the guide on... ServiceNow Discovery and CMDB.
Block 3: After go-live, measure health and treat exceptions.
After going live, CMDB governance becomes measurable. The CMDB Health score aggregates three KPIs: completeness (mandatory and recommended fields filled in), correctness (orphaned, obsolete, and duplicate CIs), and compliance (audit results). documentation of CMDB Health KPIs It states that, in the default configuration, a CI (Control Indicator) is considered obsolete when it is not updated within 60 days, a period that can be adjusted per class.
| Control item | Owner | Evidence | Suggested frequency |
|---|---|---|---|
| Revised CMDB Health Dashboard: Completeness, Correctness, and Compliance | Configuration Manager | Score by class and action plan | Monthly |
| Duplicates are addressed at the root cause, not just in the records. | CMDB Administrator | Deduplication tasks resolved and identification rule revised. | Monthly |
| Obsolete CIs investigated: import feed failing or immature lifecycle. | Classy owner | List with the destination of each CI (update, remove, or archive) | Monthly |
| Orphaned CIs: active cleanup routine and approved deletions in Data Manager. | CMDB Administrator | Tasks for removing dependent CIs completed. | Monthly |
| Data Manager policies (archive, attestation, certification, delete, and retire) published for the main classes. | CMDB Administrator | Published and scheduled policies | Semester review |
| Data Certification: what to certify, by when, and by whom. | Configuration Manager | Certification tasks completed on time. | According to policy, for example quarterly. |
| Owner attestation of CIs, including handling of duplicates. | Classy owner | Closed certification tasks | According to the policy |
The 4MATT process guide adds three practical guidelines. First, CIs that are obsolete for more than 60 days usually indicate a failure in lifecycle management, and those that exceed 90 days require manual remediation, which is laborious. Second, before blaming the lifecycle, confirm that all imports are running and that there is notification when a failure occurs. Third, the Cleanup Orphan CIs routine runs every 30 minutes by default and depends on the CSDM Activation plugin, and deletions require Data Manager approval.
The Data Certification This deserves special attention in regulated sectors. It generates recurring tasks for those responsible to verify specific attributes, such as the operating system of servers in a location, and the documentation indicates that certification records are retained and archived separately from other types of policy, which helps maintain evidence for auditing.
Block 4: Connect the CMDB to the processes that depend on it.
A CMDB (Computer-to-Database) is only sustainable when the processes that consume it also feed into it. This checklist section links CMDB governance to day-to-day operations.
| Control item | Owner | Evidence | Suggested frequency |
|---|---|---|---|
| Changes are only made to CIs upon authorized request, and closing the change includes updating the CMDB. | Change Manager | Changes completed with updated CI. | Continuous, with monthly sampling. |
| Incidents and problems recorded with CI and responsible group filled in. | Incident Manager | Percentage of records with associated CI. | Monthly |
| CIs and assets reconciled between CMDB and IT asset management (ITAM) | ITAM Leader | Report of CIs without assets and assets without CIs. | Monthly |
| Services used by AI automation and agents with owners and validated relationships. | Service owner | Critical relationships reviewed | Quarterly |
| Effectiveness of the process reported to leadership. | Owner of the process | CMDB Health Executive Report | Quarterly |
Warning signs: what each symptom indicates
When the checklist fails, the symptom appears before the cause. The table below relates the most common signs to the starting point of the investigation.
| Symptom | Probable cause | Where to act first |
|---|---|---|
| Recurring duplicates | Divergent identification rules between sources that feed the same class. | Map which classes each source feeds and align the rules at the point of intersection. |
| Many obsolete ICs | Failing imports or unmanaged lifecycle | Import jobs and notifications, then lifecycle policies. |
| Incidents referred to the wrong team. | Class without Managed by group | Ownership configuration in CI Class Manager |
| Invalid relationships | CIs deleted or merged without reconciling the references. | Routine for cleaning up orphaned files and approval in Data Manager. |
| Correct data, but no confidence in the operation. | Lack of periodic certification and attestation. | Data Certification and Attestation Policies |
How to apply CMDB best practices without trying to cover the entire CMDB.
- Assess the current situation. Use the CMDB Health Dashboard and Success Advisor to obtain a baseline by class, and record checklist items that currently have no owner or evidence.
- Restrict the scope. Apply the four blocks first to critical services and core classes, and only then broaden the coverage.
- Formalize the rituals. Schedule the monthly health review, publish the RACI matrix, and present the quarterly report to leadership.
4MATT is a ServiceNow Elite Partner in Brazil, with over 80 certified specialists, and conducts configuration management, ITAM, and ITOM projects with defined scope and pricing, or as managed services without hour allocation. To learn more about our approach, see our service description. Configuration management and CMDB.
Frequently Asked Questions
What is a CMDB governance checklist?
It is a list of verifiable controls that maintain the quality of the CMDB data over time. Each control has an owner, evidence of execution, and review frequency, and covers the planning, implementation, and operation phases.
How often should you review the health of the CMDB?
As a starting point, monthly updates are made to the CMDB Health Dashboard for the handling of duplicates and obsolete data, in accordance with the certification and attestation policy. The standard obsolescence period is 60 days and can be adjusted by class, according to criticality.
Who is responsible for the governance of the CMDB?
The process owner defines the mission and rules, the Configuration Manager approves and monitors execution, the administrator configures classes, policies, and rules, and the class owners are responsible for the accuracy of the CIs in their area. In small teams, one person can handle multiple technical roles, but responsibility for the process should remain clearly defined.
How can I tell if my CMDB is healthy?
Monitor the CMDB Health completeness, correctness, and compliance KPIs and verify that the main classes have a defined assignee, revised reconciliation rules, and published Data Manager policies. The article about Healthy CMDB It details how to measure quality by business outcome.
Do I need to apply all the CMDB best practices in a small environment?
No. The principle is proportionality: start with critical services and core classes, maintain ownership and evidence for each control, and expand coverage as the team is able to keep the data up to date.