How to Set Realistic Data Quality Targets for CMDB

CMDB data quality targets: make them specific enough to achieve

“Reach 100% CMDB compliance.”

“Fully align with CSDM.”

“Fix every record.”

These may sound like reasonable data-quality goals, but they are usually too broad to turn into practical work.

A large CMDB may contain thousands or millions of records, multiple data domains, different owners, automated sources, integrations, and constantly changing information.

Even if the data reaches 100% compliance for a moment, it may not stay there.

People leave.

Applications change.

New records are created.

Relationships are added or removed.

Requirements evolve.

A more useful approach is to break the big target into smaller, measurable goals that specific people or teams can actually influence.

Why 100% CMDB compliance is often the wrong first target

The problem with 100% compliance is not that high quality is undesirable.

The problem is usually the scope.

A target becomes difficult to manage when it combines:

• Every CMDB record
• Every data-quality requirement
• Every CSDM relationship
• Every data domain
• A permanent expectation of 100% compliance

That is a very different challenge from saying:

“All of our critical Business Applications should have a valid owner.”

or:

“Every Business Application owned by this team should meet these five minimum requirements.”

Those are clear targets.

They have a defined scope and someone can be accountable for reaching them.

Use CSDM as a direction, not one giant delivery milestone

“Implement CSDM” is another target that can become too vague.

CSDM covers multiple areas of ServiceNow data and is deliberately designed to support progressive adoption.

ServiceNow itself recommends a staged approach rather than trying to implement the entire model at once. Its CSDM 5 guidance organizes adoption across Foundation, Crawl, Walk, Run, and Fly stages, with different data objects and outcomes introduced over time. ServiceNow's CSDM 5 guidance provides the full staged model.

Even the Crawl stage can still be a large target.

It may involve:

• Business Applications
• Service Instances or Application Services
• Supporting infrastructure
• Relationships between those records
• Ownership and foundation data

For a large organization, that may already involve thousands of records and hundreds of people.

The solution is to break the stage down further.

A five-step model for realistic CMDB data quality targets

The session introduces a five-step method for turning broad CMDB or CSDM goals into manageable targets.

The steps are:

1. Select a data domain and assign an owner.
2. Identify the data providers responsible for individual records.
3. Define minimum data requirements.
4. Move toward the target data model.
5. Continue raising the maturity level over time.

Instead of trying to solve the whole CMDB at once, the same process can be repeated across different domains.

The demo uses Business Applications as the example.

Step 1: choose one CMDB or CSDM domain

Start by narrowing the problem.

Instead of:

“Improve our CMDB.”

choose a specific domain such as:

• Business Applications
• Application Services
• Servers
• Service Offerings
• Locations
• Another high-value data area

Then identify the person or team responsible for the overall quality of that domain.

For Business Applications, that might be an Enterprise Architecture or application portfolio team.

The domain owner does not necessarily maintain every record.

Their responsibility is to make sure the domain is governed, monitored, and improving.

Step 2: make sure every record has a data provider

Before adding more quality requirements, identify who is responsible for maintaining the individual records.

For Business Applications, this may be the Application Owner.

One owner might maintain several applications.

Across a large portfolio, hundreds of people may therefore be involved.

This is why ownership is a useful early target.

Before asking people to improve lifecycle data, relationships, architecture information, or other attributes, first make sure each record has someone who can actually respond.

A practical first target might be:

90% of active Business Applications have a valid data provider.

Once that baseline is in place, it becomes much easier to distribute the next set of requirements.

Validate that the owner is still valid

Simply populating the owner field is not always enough.

The referenced person also needs to be valid.

For example, an Application Owner may have left the organization.

That means an ownership completeness score could look healthy while the governance process is already broken.

A stronger target can therefore include checks such as:

• The owner reference is populated
• The referenced user is active
• A Managed by Group or supporting team exists where required

This gives the next stages of data-quality work somewhere to go.

Step 3: define a true minimum data standard

Once responsibility is reasonably clear, introduce a small number of useful requirements.

The key word is minimum.

Do not immediately add everything the organization may eventually want.

Choose information that is:

• Useful now
• Relatively easy to provide
• Relevant to real ServiceNow processes
• A foundation for later requirements

In the Business Application example, this may include:

• Name
• Description
• Business Criticality
• Architecture Type
• Duplicate detection

Business Criticality, for example, may already support incident or change-management decisions.

Architecture Type may later help determine which additional data requirements apply.

The first target should create useful data without overwhelming the providers.

Measure each maturity step separately

One useful part of the approach is that each stage can have its own metric.

For example:

Ownership target

94% of Business Applications have valid providers.

Minimum-data target

82% meet the agreed baseline fields and duplicate checks.

Target-model compliance

81% meet the broader Business Application Crawl requirements.

The exact numbers are less important than the structure.

Instead of one score trying to represent everything, teams can see which part of the maturity journey is working and where the next gaps remain.

Step 4: move toward the target CSDM model

Once ownership and minimum data are working, the organization can introduce the more demanding requirements that were part of the original target.

For Business Applications, this may include the relationships required for the chosen CSDM stage.

At this point, the organization is no longer trying to introduce those relationships into an unmanaged data set.

There is already:

• A defined domain
• An accountable owner
• Known data providers
• A minimum data standard
• An established audit process

That makes the CSDM target much more achievable.

Break even the CSDM Crawl stage into smaller targets

A useful insight from the session is that the Crawl stage itself may still be too large to treat as a single milestone.

A more practical sequence might be:

1. Improve Business Application data.
2. Then focus on Application Services.
3. Then address relevant server or infrastructure data.
4. Then strengthen the relationships between those domains.

You may also decide that an optional part of the model is not currently required.

The target should reflect how your organization actually uses ServiceNow rather than treating every theoretical element as equally urgent.

Let your ServiceNow use cases determine the priority

CSDM alignment should support an outcome.

For example, your immediate priority may be:

• Improving incident impact analysis
• Making application ownership visible
• Supporting change management
• Building better service visibility
• Preparing data for automation

Those outcomes should influence which CSDM requirements come first.

This prevents the data model from becoming an abstract compliance exercise.

The question becomes:

Which data do we need next to make this ServiceNow use case work better?

Step 5: keep raising the bar after each target is reached

There is no permanent final state for CMDB data quality.

Once the target model is performing well, the organization can introduce additional requirements.

That may mean:

• Adding more attributes
• Introducing new relationship requirements
• Moving to the next CSDM maturity stage
• Expanding from critical records to a wider scope
• Adding another data domain

The process continues as the organization's needs mature.

What changes is that each improvement becomes another explicit target rather than an uncontrolled expansion of the original scope.

Use separate targets when different requirements need different attention

Not every requirement needs to be measured or governed in exactly the same way.

For example, valid ownership may be considered critical enough to target close to 100%.

A more advanced relationship requirement may initially have a lower target.

Different Blueprints or audit views can also be used when separate groups are responsible for different parts of the same data.

This gives teams more flexibility than forcing every requirement into a single CMDB-health percentage.

When does a 100% data quality target make sense?

A 100% target is not always unrealistic.

It becomes much more reasonable when the scope is limited.

For example:

100% of my five Business Applications meet the agreed minimum requirements.

That is very different from:

100% of all CMDB data is CSDM compliant.

A 100% target may also make sense for:

• A small set of business-critical applications
• A narrowly defined ownership requirement
• A selected regulatory or operational scope
• A specific team responsible for a manageable number of records

At enterprise scale, a slightly lower target may be more realistic because data continuously changes.

Use different targets for critical and non-critical data

Not every record needs the same quality target.

For example:

• Critical Business Applications: 100%
• Lower-criticality applications: 90%

The exact percentages depend on the organization.

The important idea is that the quality target reflects the value and risk of the data.

This helps teams concentrate effort where poor data would create the greatest impact.

Make personal targets achievable

A target becomes much more useful when the person responsible can see how their actions affect it.

An Application Owner responsible for five applications may reasonably be expected to keep all five compliant with a small number of clear requirements.

That person can see the remaining gaps and fix them.

By contrast, they cannot meaningfully influence an enterprise-wide CMDB score covering millions of records.

Personal or team-level targets make responsibility much more concrete.

Use audits to turn targets into measurable progress

A target only becomes useful when it can be measured consistently.

In the demo, Blueprints define the requirements and audits compare live ServiceNow data against them.

The results show:

• The current compliance level
• Trend over time
• Records with critical deviations
• Which Blueprint elements fail most often
• Which requirements should be addressed next

This provides a clear connection between the agreed target and the actual state of the data.

The ServiceNow data quality audit walkthrough goes deeper into the auditing part of this process.

Use the findings to decide the next target

The next target should not always be chosen in advance.

Audit results can show which problems are most important after the current baseline is reached.

For example, the target-model audit in the session shows that Application Owner information is already strong while Support Group and Managed by Group information have larger gaps.

That gives the team a natural next priority.

Instead of adding arbitrary new requirements, the organization can use real audit findings to decide where the next improvement effort will have the greatest value.

Celebrate smaller data-quality wins

A large transformation goal can take years.

If success is only recognized when the entire CMDB reaches the final target, people may never feel that progress has been made.

Smaller targets create more opportunities to show improvement.

For example:

• 95% of Business Applications now have an owner
• Critical applications have reached the minimum-data target
• Five data domains now have defined owners and audits
• A team has reached 100% compliance for its own applications

These milestones make progress visible and help motivate the people doing the work.

They also make it easier to communicate the program to management.

A practical framework for realistic CMDB data quality targets

A simple way to apply the approach is:

1. Choose one domain. Do not start with the entire CMDB.
2. Assign overall ownership. Identify who is accountable for improving that domain.
3. Identify data providers. Make sure individual records have people who can maintain them.
4. Set minimum requirements. Start with a small number of useful fields and checks.
5. Introduce the target model. Add the relationships and requirements needed for your actual ServiceNow use cases.
6. Measure progress. Track each stage separately rather than hiding everything inside one health score.
7. Raise the bar gradually. Add requirements, records, or domains as the process matures.
8. Recognize success. Make completed milestones visible before moving to the next one.

The final goal can still be ambitious.

The difference is that the route to reaching it becomes measurable and achievable.

Related resources

• How to Engage Your Data Providers – see how broad CMDB targets can be translated into personal goals and actionable remediation work.
• How to Establish Ownership in Your CMDB – practical guidance for defining domain owners, providers, and accountability.
• DCM Blueprint Library – explore reusable starting points for different ServiceNow data domains and CSDM stages.
• How to Audit Your ServiceNow Data Quality – learn how defined requirements can be compared with live records.
• CMDB Data Quality Playbook – a broader framework for building a repeatable CMDB data-quality process.