What’s New in DCM 6.4

ServiceNow data quality audits: finding issues is only the first step

Running a data quality audit once is useful, but keeping that audit reliable, understandable, and actionable over time is much harder.

As ServiceNow data quality work matures, the scope usually grows. Teams may begin with a few straightforward checks for missing owners or support groups, then expand into relationships, lifecycle data, CSDM alignment, foundation data, certification, remediation, and governance reporting.

That growth is useful, but it creates a new challenge: the audit process itself needs to stay manageable.

A scalable ServiceNow data quality audit should help people answer three questions clearly:

• What are we checking?
• Why does it matter?
• What happens when the data fails?

About this guide: This article is based on an original DCM Open House walkthrough focused on how ServiceNow teams can maintain and scale data quality audits as requirements, ownership, certification, and remediation processes become more complex.

What is a ServiceNow data quality audit?

A ServiceNow data quality audit is a structured check that compares records against defined rules or expectations.

The goal is to identify data that is incomplete, inconsistent, outdated, invalid, or not fit for its intended purpose.

In a CMDB or CSDM context, this could include checking whether:

• Business Applications have valid owners
• Application Services have the expected relationships
• Configuration items have valid support groups
• Lifecycle status is being used consistently
• Foundation data is complete and current

The audit itself is not the end result.

The value comes from what happens next: prioritising issues, assigning them to the right people, correcting them, validating the result, and tracking whether the same problems return.

For a more focused walkthrough of the audit process itself, see ServiceNow data quality audits.

Why audit maintainability matters

A small audit is easy to understand.

A large audit can quickly become difficult to explain.

As the process grows, teams may add:

• More detailed rules
• Different conditions for different classes
• Exceptions
• Different owners for different data domains
• Scheduled and on-demand audit runs
• Certification requirements
• Remediation workflows
• Trend reporting

If that complexity is not managed carefully, several problems can appear.

People may stop trusting the findings. Data providers may receive irrelevant tasks. Platform teams may spend too much time explaining why a rule failed. Dashboards may show poor quality without making the next action clear.

A maintainable audit process keeps the logic understandable and the findings practical.

Start with the data that creates the most risk

A scalable audit programme should not try to check everything simply because the data exists.

The strongest starting point is data that supports an important business, operational, governance, or automation outcome.

That may include:

• Application ownership
• Support groups
• Service relationships
• Lifecycle status
• Business criticality
• Assignment groups
• User data
• Key foundation records

A useful question is:

What would create operational risk if this data was wrong?

If poor data could affect incident routing, change impact analysis, reporting, compliance, automation, AI outputs, or accountability, it is a strong candidate for auditing.

This helps avoid a common mistake: creating a large number of checks without a clear reason for why those checks matter.

Make every audit rule easy to explain

A technically correct rule can still be difficult to use if nobody understands it.

Each audit rule should make clear:

• What is being checked
• Which records the rule applies to
• Why the check matters
• What the expected outcome is

This matters especially when findings are shown to people outside the ServiceNow or CMDB team.

For example:

“Business Application owner is missing or inactive”

is much easier to understand than exposing a technical condition or encoded query.

Clear audit messages also help people act.

A failed result should tell the data provider what is wrong and what needs to happen next.

If the message is too technical or vague, the finding is more likely to be ignored, escalated, or corrected incorrectly.

Use scheduled and on-demand audits for different purposes

Not every audit needs to run in the same way.

Scheduled audits are useful for continuous monitoring.

They help teams track recurring quality issues and keep important data under regular review.

This works well for data such as:

• Ownership
• Support groups
• Lifecycle status
• Relationships
• Foundation data

On-demand audits are useful when a team needs to assess a particular area before a specific initiative.

That might include:

• A migration
• A certification round
• A governance review
• A CSDM improvement project
• A ServiceNow transformation
• Testing a new data quality rule

A mature operating model will usually use both.

Scheduled audits provide continuity, while on-demand audits give teams flexibility when priorities change.

Connect audit findings to the people who can fix them

An accurate audit result is not very useful if nobody is responsible for acting on it.

A scalable audit process needs to connect findings to the people or teams who actually understand the data.

The right owner depends on the domain.

Application data might belong to application owners or portfolio teams.

Service data may belong to service owners.

Infrastructure data may belong to operations teams.

Foundation data might sit with HR, finance, facilities, vendor management, or platform administration.

The important point is that the CMDB or platform team should not automatically become responsible for every data problem.

The central team can define the rules, coordinate the process, and provide visibility.

The people closest to the data should usually validate or correct it.

This is also why ServiceNow data governance and data quality audits need to be connected. Governance defines responsibility; audits make those responsibilities actionable.

Reduce audit noise before people stop paying attention

One of the biggest risks in data quality work is creating too many findings.

Audit noise can happen when:

• Rules are too broad
• Exceptions are not handled properly
• Low-impact issues are treated as critical
• The same unresolved issue is repeatedly surfaced without useful context
• Findings do not lead to any meaningful action

The goal is not to create the largest possible list of data quality problems.

The goal is to create the most useful list of problems.

Teams should regularly ask whether each rule leads to a decision, correction, certification task, or governance discussion.

If it does not, the rule may need to be refined or removed.

Use certification when audit rules cannot prove correctness

Some data quality issues can be detected automatically.

Others require human judgement.

An audit can tell you that an owner field is populated.

It cannot always tell you whether the person is still the correct owner.

An audit can detect that a relationship exists.

It may not know whether that relationship reflects the real operational environment.

That is where ServiceNow data certification adds value.

Certification asks responsible people to confirm whether important data is actually correct.

A strong process therefore uses:

• Audits to detect missing, invalid, inconsistent, or risky data at scale
• Certification to validate information that requires real-world knowledge

The Open House on blueprint-based data certification goes deeper into how those two parts can work together.

Track trends, not only pass or fail results

A single audit run gives you a snapshot.

Trend data tells you whether the process is improving.

Useful questions include:

• Is overall data quality improving or declining?
• Which rules fail most often?
• Which teams have recurring issues?
• How quickly are issues being resolved?
• Do the same problems return after being fixed?

This can reveal operating-model problems that a single audit result may not show.

For example, recurring missing owners may point to a weak onboarding or ownership-change process.

Repeated relationship issues may point to discovery, integrations, or service modelling.

Slow remediation may indicate unclear responsibility or poor task context.

Trend reporting therefore helps move the conversation from:

“The data is bad.”

to:

“This is where the process keeps breaking down.”

Review the audit process like any other operational process

A data quality audit should not be designed once and then left untouched.

As ServiceNow processes, data models, ownership, and business requirements change, the audit logic should evolve with them.

A useful review can ask:

• Does every rule still have a clear purpose?
• Are the audit messages understandable?
• Are findings routed to the right people?
• Are scheduled audits running at a useful frequency?
• Are recurring failures pointing to a bigger process issue?
• Are there rules producing noise rather than useful action?
• Do some findings need remediation while others need certification?

Some findings may require a straightforward correction.

Others may point to:

• A data-model change
• A source-system issue
• A governance gap
• A process problem
• An accepted exception

The audit process should make those distinctions easier to see.

Scale the process without making the rules harder to use

Scaling data quality does not mean making every rule more sophisticated.

In many cases, the most scalable approach is to keep the expectations as clear as possible.

A practical model might be:

1. Start with a small number of high-value data requirements.
2. Document why each rule exists.
3. Route failed records to the right owners.
4. Use scheduled audits for continuous monitoring.
5. Use on-demand audits for projects and one-off reviews.
6. Add certification where automatic rules cannot prove correctness.
7. Track trends and recurring failures.
8. Refine the rules when they create noise or stop being useful.

Reusable data quality blueprints can support this by keeping requirements explicit rather than scattering audit logic across individual projects.

Move from audit reporting to continuous improvement

The strongest audit programmes do more than expose bad data.

They create a repeatable way to improve it.

That means connecting:

• Defined data quality requirements
• Audit results
• Ownership
• Remediation
• Certification
• Trend reporting
• Governance

If a finding identifies a problem but nobody acts on it, the audit has limited value.

If recurring findings reveal why the problem keeps returning, the audit becomes a tool for improving the wider operating model.

That is the point where data quality auditing becomes more than monitoring.

It becomes a practical process for keeping CMDB, CSDM, foundation, and operational ServiceNow data trustworthy over time.