CRM data quality audit: baseline scan, continuous checks, and quarterly review

A dashboard reporting 96% field population looks like a clean database. It can sit next to a 5% duplicate rate, a stale former-customer account still reading Customer, and an opt-out who never should have gone dark on a renewal. Field population is one signal. It is not an audit.

A CRM data quality audit is a scoped, repeatable check with a severity model, a baseline, and two different cadences: continuous checks that catch known problems as they recur, and a quarterly review that tests whether the checking system itself still works. Skipping either half leaves a gap the other one can't see.

An audit answers a narrower question than "is the data good?"

"Is the data good?" isn't answerable. "Is the data good enough for the decisions we're making with it, and do we know where it isn't?" is. Scope the audit around that question:

Scope decision	What it controls
Population	Which objects and segments are in scope (Leads, Contacts, Accounts; active vs. archived; which business unit)
Severity model	What makes a finding high, medium, or low severity
Baseline metrics	The specific numbers the audit tracks over time
Cadence	Which checks run continuously and which run quarterly
Owner	Who reviews findings and who can change the rules that produce them

Skip the severity model and the audit produces a flood of low-value findings nobody triages, which is how audits get abandoned after one run. A finding that blocks a handoff or a send is not the same as a finding that's cosmetic.

Severity	Definition	Example
High	Blocks a handoff, a send, or a report population if unresolved	An ambiguous duplicate pair both getting outreach
Medium	Degrades a report or automation but doesn't block anything	A phone number in the wrong format
Low	Cosmetic or low-frequency; batched for periodic cleanup	Inconsistent capitalization on a free-text field

Baseline metrics need a stated denominator

A percentage without a population attached to it is not a metric. "Duplicate rate: 1%" means nothing until you know it's 1% of active Contacts, not 1% of all records ever created including the ones already merged away last quarter.

Track these six baseline metrics, each with its denominator stated:

Duplicate rate: duplicate groups found ÷ records scanned, for the population and object types in scope.
Normalization failure rate: records failing a validation rule ÷ records evaluated against that rule.
Core-field population rate: required fields populated ÷ required fields expected, scoped to the segment where they're actually required (a field can be legitimately empty for a segment it doesn't apply to).
Stale-account count: Accounts reading an active commercial status with no activity inside the defined staleness window.
Consent/DNC coverage rate: records with an explicit consent, opt-out, and DNC state recorded ÷ records where that state should exist.
Enrichment spend rate: credits or dollars spent ÷ eligible records enriched, which exposes when spend is climbing faster than eligible population growth.

A high fill rate on core fields (metric 3) tells you nothing about metrics 1, 4, or 5. That's the whole argument against treating field population as a proxy for trustworthy data: it measures one dimension and stays silent about the rest.

Continuous checks and quarterly audits ask different questions

Continuous checks catch a known problem recurring. A nightly duplicate scan catches new duplicates created since last night. A validation rule on the phone field catches a bad format the moment it's entered. These checks are only as good as the specific problems they were built to look for.

A quarterly audit asks a different question: does the operating system itself still work? A continuous check can pass every night while the underlying rule has drifted out of date, a trigger silently stopped firing, or a new record type nobody scoped into the original rules is quietly accumulating the exact problem the continuous check was supposed to catch. Quarterly review re-scopes the population, re-validates the rules against current business reality, and looks for the class of failure that "still passing" continuous checks can't see by design.

Cadence	Catches	Owned by	Fails silently if...
Continuous	Recurrence of a known problem type	The team whose workflow the problem affects	The rule itself has drifted or a scope gap opened up
Quarterly	Whether the rules, triggers, and ownership still match reality	Revenue Operations or a designated data-quality owner	Nobody actually reviews the findings, or the review has no authority to change anything

Don't let a string of green continuous-check runs stand in for the quarterly review. They're answering different questions.

A scan needs four distinct states, not two

"Passed" and "failed" isn't enough for a scan or audit run. Use four states:

Running: the scan is in progress; don't read its partial output as current.
Last successful: the most recent complete run; this is what the dashboard should show by default.
Stale: the last successful run is older than the expected cadence; something isn't running when it should.
Partial failure: the run started but didn't complete every rule family; this is not the same as failure of the whole scan, and it's not the same as success either.

The rule that matters most: a failed or partial run must never silently overwrite the last successful snapshot. If a scan fails halfway through and its incomplete result becomes "current," the dashboard reports a worse population as if it were verified, and nobody notices because nothing looks broken. Promote a new snapshot to current only after the rule families required for that promotion have all completed. A partial run stays labeled partial, visible, and routed to its owner, while the last good snapshot keeps serving as the current state until a new complete run replaces it.

GTM Lab: the audit that should have run a year ago

GTM Lab, a fictional B2B software company selling to mid-market manufacturers, inherited a CRM population nobody had audited in over a year. Small issues (a few duplicates a week, a handful of unvalidated bulk imports) compounded into a population-wide problem invisible from any single record view.

Scoping the first audit without a severity model produces this result:

Approach	What happens
Scan "everything, every field," no severity model	4,200 findings returned in one run; no way to tell which ten matter today; the audit gets shelved
Scan the in-scope population with a severity model	4,200 findings sort into 60 high-severity (blocking), 900 medium, and the rest low; the team clears the 60 in a week and schedules the rest

The scoped version is the one that survives past its first run. The baseline it produces (duplicate rate, normalization failure rate, core-field population, stale accounts, consent/DNC coverage, enrichment spend rate, each with its population and date stated) becomes the number every later chapter's policy is measured against.

This is a worked example. GTM Lab's specific thresholds and severity cutoffs aren't a universal standard; the structure (scope, severity model, six baseline metrics, four-state scan model, continuous-plus-quarterly cadence) is what carries over to a real CRM.

Salesforce and HubSpot: what changes, what doesn't

Salesforce's duplicate rules and matching rules can flag or block potential duplicates at save time, and reports can surface field-population gaps by object. Neither one gives you a severity model, a baseline history, or a quarterly-review process; those are yours to design regardless of which platform's native tools you point at the continuous-check layer.

HubSpot's deduplication tools and property requirements give you similar building blocks: managed dedupe review and field-level validation. Same caveat: the audit program (scope, severity, cadence, ownership) is a design decision the platform doesn't make for you.

CRM data quality audit checklist

Population scope is explicit: which objects, which segments, what's excluded and why.
A severity model exists and every finding gets a severity, not just a count.
All six baseline metrics are tracked, each with its denominator and date stated.
Continuous checks and the quarterly audit are both defined, with what each one catches written down.
The scan runtime distinguishes running, last successful, stale, and partial failure.
A failed or partial run never overwrites the last successful snapshot.
Every high-severity finding has an owner and a resolution path.
The quarterly review has the authority to change a continuous-check rule, not just report on it.
The baseline is re-run on a stated cadence, not only once.

Where this connects

The identity work in duplicate detection, merge review, and survivorship and the format work in CRM normalization and validation rules are the two continuous checks this audit most often surfaces first. If the audit points toward building dedicated tooling instead of using what you already have, work through buy, configure, connect, or build before reaching for the DIY Database Health Center pattern, which documents the scan/snapshot runtime model this page's four-state rule is based on in more implementation depth.