Data Certification Demo

ServiceNow data certification: start with a process people can actually use

Data certification can help build trust in ServiceNow data, but only if the process is practical for the people being asked to take part.

If teams are asked to certify too much data at once, receive unclear review tasks, or do not know what happens after they reject something, certification can quickly become another administrative exercise.

A useful ServiceNow data certification process should answer a simple question:

Can we trust this data for the purpose it is meant to support?

That matters across CMDB, CSDM, ownership, reporting, automation, compliance, and AI-readiness.

About this guide: This article is based on an original DCM Open House session focused on how ServiceNow teams can introduce data certification in a practical way, starting with clear scope, understandable tasks, the right reviewers, and a defined follow-up process.

What does data certification mean in ServiceNow?

Data certification is a structured process for asking responsible people to review selected ServiceNow data and confirm whether it is accurate, complete, and fit for use.

That may mean asking an application owner to confirm:

• The owner is still correct
• The lifecycle status is current
• The support group is appropriate
• The related services are correct

A service owner might be asked to validate important service relationships.

A foundation-data owner might review locations, departments, companies, users, or groups.

The important point is that certification is not only a completeness check.

A field can contain a value and still be wrong.

Certification adds human validation where ServiceNow rules alone cannot determine whether the data reflects reality.

For a broader overview of the approach, see ServiceNow data certification.

Start with one focused certification use case

One of the easiest ways to make certification difficult is to start too broadly.

If the first round includes too many tables, too many fields, and too many reviewers, the process becomes harder to explain and harder to manage.

A more practical approach is to choose one use case where poor data already creates visible friction.

Ownership data is often a strong starting point.

If application owners, service owners, support groups, or technical owners are incorrect, it becomes harder to:

• Assign remediation work
• Route operational tasks
• Validate records
• Maintain accountability
• Escalate issues to the right people

Other useful starting points might include:

• Lifecycle status
• Critical CMDB relationships
• Application Service information
• Foundation data
• Data used in reporting or compliance

The first certification round should be important enough to matter, but small enough to manage.

Certify the data that creates real operational or governance risk

Not every field needs a certification process.

The goal is not to ask people to manually review everything in ServiceNow.

A useful question is:

What would break, slow down, or become unreliable if this data was wrong?

Good candidates for certification can include:

• Business Application owners and technical owners
• Service and Service Offering owners
• Support groups
• Lifecycle status
• Critical CMDB relationships
• Foundation data such as users, locations, companies, departments, and groups
• Data used in compliance, reporting, automation, or AI

This keeps the process tied to business and operational value rather than turning certification into a generic data-review campaign.

Send certification to the people who understand the data

Certification works best when the reviewer is close enough to the data to know whether it is actually correct.

That person is not always part of the ServiceNow platform or CMDB team.

Depending on the data, the right reviewer may be:

• An application owner
• A service owner
• A product owner
• An application portfolio manager
• An infrastructure or operations team
• HR
• Finance
• Facilities
• Vendor management

The central ServiceNow, CMDB, or governance team can define the process, reporting, schedule, and criteria.

But the actual validation should involve the people who understand what the data represents in practice.

This is an important distinction.

Instead of saying:

“The business owns the data.”

certification turns ownership into a concrete responsibility:

Review this information, confirm whether it is correct, and help resolve it if it is not.

Make certification tasks specific enough to answer properly

A certification task should make it obvious what the reviewer is being asked to validate.

A generic request such as:

“Please certify this Business Application.”

leaves too much room for interpretation.

One reviewer may check ownership.

Another may look at lifecycle status.

Another may simply approve the record because nothing appears obviously wrong.

A better certification request should explain:

• What data is being reviewed
• Why the data matters
• Which fields or relationships the reviewer should check
• What correct data should look like
• What the reviewer should do if something is wrong

For example, if the goal is application ownership certification, the task should make that specific rather than asking someone to review the entire application record.

Clearer tasks lead to more consistent answers and make the resulting certification data more useful for governance.

Use data quality audits before asking people to certify everything

Audits and certification solve different problems.

A data quality audit can automatically check whether data meets defined requirements.

For example, an audit can identify:

• A missing owner
• An inactive support group
• A missing relationship
• An invalid lifecycle value
• A record that does not meet a defined rule

Certification becomes useful when the question is not simply whether the data exists, but whether it is actually correct.

An audit may confirm that every Business Application has an owner.

It cannot always determine whether that owner is still the right person.

A practical process therefore looks like this:

1. Define the expected data requirements.
2. Audit the ServiceNow data against those requirements.
3. Identify which records or attributes require human validation.
4. Send certification to the appropriate reviewers.
5. Create follow-up actions for rejected or incorrect data.
6. Track recurring issues and progress over time.

This prevents certification from becoming unnecessarily broad.

You can see the automated side of the process in the ServiceNow data quality audit walkthrough.

Avoid certification fatigue

Certification fatigue happens when people receive too many requests or when the tasks feel disconnected from anything useful.

Common causes include:

• Sending too many certification tasks at once
• Asking people to validate data they do not understand
• Providing vague instructions
• Repeating certification too frequently
• Failing to act on rejected data
• Asking reviewers to certify low-value information

The best defence is relevance.

Keep the scope focused.

Explain why the data matters.

Make each task specific.

Send it to someone who actually understands the information.

And make sure the reviewer can see that their response leads to action.

If certification becomes a checkbox exercise, people may simply approve records without reviewing them properly.

Choose the certification frequency based on risk and change

There is no single certification schedule that works for every type of ServiceNow data.

Frequency should depend on:

• How important the data is
• How often it changes
• What risk is created if it becomes outdated

Ownership and support information for business-critical applications may need relatively frequent review.

More stable data may only need certification quarterly, twice a year, or around a specific governance event.

Certification can also be triggered by initiatives such as:

• An audit
• A migration
• A CSDM improvement programme
• An AI-readiness initiative
• A major ServiceNow transformation

The objective is to maintain enough confidence in the data without creating unnecessary review work.

Define what happens when someone rejects the data

A certification process does not improve anything if rejection is the end of the workflow.

When a reviewer says the data is wrong, there should be a clear next step.

Depending on the problem, that might include:

• Correcting the record
• Creating a remediation task
• Updating the data owner
• Reviewing the source process
• Changing a data quality rule
• Escalating a recurring issue into governance

This is also where certification can reveal problems that are bigger than one record.

If many reviewers reject data for the same reason, the issue may point to:

• A weak integration
• An unclear ownership model
• An outdated maintenance process
• A confusing data model
• A missing governance decision

Certification can therefore tell you more than which records are wrong.

It can show where the wider data quality operating model needs attention.

Use certification to make ownership practical

Many organisations already say that data should have an owner.

The harder part is making that ownership operational.

Certification is one way to do that.

Instead of ownership existing only as a field on a record or as a governance principle, the responsible person is given a defined action:

• Review the data
• Confirm what is correct
• Reject what is wrong
• Help resolve the problem

This is why certification connects naturally with ServiceNow data governance.

Governance defines who should be responsible and what standard is expected.

Certification gives those responsibilities a repeatable operational process.

Start small, learn, then expand

A first ServiceNow certification process does not need to cover the whole platform.

A practical starting sequence is:

1. Choose one important data area.
2. Define exactly what needs to be validated.
3. Identify the people who understand that data.
4. Create specific certification tasks.
5. Decide what happens when data is rejected.
6. Run a manageable first round.
7. Review what worked and what created confusion.
8. Refine the process before expanding the scope.

Ownership, Business Applications, Application Services, support groups, lifecycle data, and selected foundation data can all be useful starting points.

If reviewers understand what they are being asked to do and can see the impact of their decisions, certification is much more likely to become part of normal data quality work.

Make certification part of an ongoing data quality process

A one-time certification round may temporarily improve confidence in the data.

But ServiceNow data changes constantly.

People change roles. Services evolve. Applications move through lifecycle stages. Relationships change. Groups become inactive.

That means certification works best when it is part of a wider ongoing process that combines:

• Clear data quality requirements
• Automated audits
• Human validation
• Ownership
• Remediation
• Trend reporting
• Continuous improvement

The blueprint-based data certification Open House goes further into how reusable data-quality definitions can make that process more consistent and repeatable.

The broader CMDB Data Quality Playbook also provides a wider framework for moving from isolated data issues toward a more sustainable data quality operating model.