HubSpot Data Governance: Build a Policy That Actually Works

Last year I helped a 200-person SaaS company clean up their HubSpot portal. Forty hours of work across two weeks. Deduplicated 3,000 contact records. Archived 180 unused properties. Standardised their industry field from 90 free-text values down to 12. Fixed 2,000 broken associations.

Six months later they asked me to do it again. The portal was back in the same state. Different duplicate records, but the same volume. New unused properties had replaced the ones I archived. The industry field had crept back to 40 values.

The cleanup worked. The governance didn't exist. Nobody owned data quality. Nobody reviewed property creation requests. Nobody monitored whether standards were being followed. So the portal decayed back to its natural state, which is chaos, because 50 people modify a CRM every day and entropy always wins unless something pushes back.

That experience changed how I think about data quality work. The cleanup is the easy part. The governance is what makes it stick.

The cost of not governing

The research makes the scale of this problem concrete.

Validity's 2025 State of CRM Data Management report surveyed 602 CRM users across the US, UK, and Australia. The headline finding: 76% said less than half of their organisation's CRM data is accurate and complete. That's not a data quality problem at the margins. That's a majority of records being unreliable.

The downstream effects are measurable. Thirty-seven percent of organisations reported losing revenue directly from poor data quality. Workers spend an average of 13 hours per week hunting for basic information in their CRM. Companies lose an average of 16 sales deals per quarter from bad data. And here's the stat that should concern anyone thinking about governance: 37% of staff regularly fabricate data to tell leaders what they want to hear. When your CRM is unreliable, people stop trusting it and start making things up.

Gartner estimates that poor data quality costs the average enterprise $12.9-15 million per year. Separately, Openprise's 2025 State of RevOps survey found that 70% of RevOps teams can't make strategic decisions because of poor data quality. Only 11% described their data as excellent.

The industry response to this problem is, counterintuitively, to invest less. Validity found that only 18% of organisations without a full-time data quality role plan to hire one in the next 12 months, a 56% decrease from 2024. Meanwhile, 57% are doing manual data cleaning while simultaneously cutting dedicated data quality personnel. More manual work, fewer people to do it. That's a governance gap, and it's widening.

Why most governance policies collect dust

I've seen dozens of data governance documents. Most share three problems.

They're written for an audience that doesn't read them. A 15-page PDF explaining data standards, naming conventions, and quality thresholds gets read during onboarding week and never again. Reps don't consult a wiki page before creating a property. Managers don't check a governance doc before approving an import. The document exists to make someone feel better about the process. It doesn't change behaviour.

They assign ownership to "the team." When everyone owns data quality, nobody does. "The RevOps team is responsible for data governance" means the most conscientious person on the team does extra work until they burn out or leave, and then nobody does it. Governance needs names attached to responsibilities, not team labels.

They describe the ideal state without explaining how to get there. "All properties should follow the naming convention" is a standard. It's not governance. Governance is: who reviews new property requests? What happens when someone creates a property without following the convention? How are existing violations identified and fixed? The enforcement mechanism matters more than the rule.

The governance policies that work are short, assign specific people, and encode as much as possible into the system rather than relying on memory.

The five sections your policy needs

A HubSpot data governance policy doesn't need to be long. Mine fit on two pages. What it needs is specificity: who does what, when, and what happens if they don't.

1. Ownership model

Every governance policy needs named owners. Not roles, not teams — people with names.

Responsibility	Owner	Cadence
Property creation requests	[Name]	Per request (48h SLA)
Monthly data quality review	[Name]	First Monday of month
Quarterly property audit	[Name]	End of Q1/Q2/Q3/Q4
Import approval	[Name]	Per import
Integration data mapping	[Name]	Per new integration

If your RevOps team is two people, the same name appears in multiple rows. That's fine. What matters is that each row has a name, not "RevOps team." When that person leaves, the handover is explicit: these five responsibilities transfer to someone specific.

For larger teams, split ownership by object. One person owns Contact and Company data quality. Another owns Deal and Pipeline governance. A third owns integrations and import standards. Object-level ownership prevents the "someone else will catch it" problem.

The ownership model is the most important section. Skip the rest if you have to, but don't skip this. The Validity data shows the industry is moving in the wrong direction: fewer dedicated data quality roles, more manual cleanup distributed across people who have other jobs. Named ownership is how you push back against that trend without hiring a full-time data governance person.

2. Property standards

Property standards define how your CRM schema should look. This is the section that replaces the 15-page document nobody reads, because it encodes rules that can be checked automatically.

Naming convention:

• Format: object_category_description (e.g., contact_marketing_last_campaign_date)
• No spaces in internal names (HubSpot allows them; don't use them)
• Lowercase with underscores
• Maximum 50 characters
• No abbreviations unless universally understood (url, id, crm)

Required metadata:

• Every custom property must have a description explaining what it stores, who uses it, and what populates it
• Every property must belong to a named property group (not "Other" or "Ungrouped")
• Every new property must have a documented business justification

Property request process:

1. Requestor checks if the property already exists (search by keyword, not just name)
2. Requestor fills in: name (following convention), type, description, group, who populates it, who consumes it
3. Property owner reviews within 48 hours
4. If approved, property owner creates it (not the requestor)
5. If the property duplicates an existing one, the owner points to the existing property instead

This process prevents the addition bias that causes property sprawl. The person who wants the property doesn't create it. The person who understands the schema does.

The property hygiene guide covers the tactical details of naming, grouping, and lifecycle management. The governance policy just needs the rules and the process for enforcing them.

3. Data quality thresholds

Thresholds define what "good enough" looks like. Without them, quality is subjective and nobody agrees on whether there's a problem.

Minimum fill rates for critical properties:

Object	Property	Minimum	Current
Contact	Email	95%	[measure]
Contact	Job title	70%	[measure]
Contact	Lifecycle stage	90%	[measure]
Contact	Company association	85%	[measure]
Company	Industry	80%	[measure]
Company	Company size	70%	[measure]
Deal	Amount	90%	[measure]
Deal	Close date	95%	[measure]
Deal	Associated contact	95%	[measure]

Fill the "Current" column from your actual portal data. The gap between minimum and current is your remediation backlog.

Quality ceilings:

Metric	Maximum	What it means
Duplicate rate	2%	Above this, deduplication is urgent
Orphan contacts (no company)	15%	Above this, association cleanup needed
Stale records (no update 12+ months)	20%	Above this, freshness remediation needed
Zombie properties (0% fill rate)	5% of total	Above this, property audit overdue

These numbers aren't universal. A portal with 5,000 contacts has different thresholds than one with 500,000. Set yours based on what your AI tools and reporting actually need. The data quality score framework explains how these components roll up into a composite score. The AI readiness scoring article covers the thresholds where AI features start working reliably.

The point is having numbers at all. "Our data quality should be good" isn't a standard. "Contact email fill rate must stay above 95%" is.

There's another reason thresholds matter: they surface problems before people start working around them. Remember the Validity finding that 37% of CRM users fabricate data? That behaviour starts when people can't find accurate information (13 hours a week searching, on average) and give up trying. Thresholds won't stop someone from entering bad data on purpose, but they will make the data quality decline visible before it reaches the point where people stop trusting the CRM entirely.

4. Review cadence

Governance without review is a suggestion. Set a cadence and protect it.

Weekly (5 minutes):

• Check automated data quality alerts (if you have monitoring in place)
• Review any flagged import failures
• Approve or reject pending property requests

Monthly (30 minutes):

• Review data quality metrics against thresholds from Section 3
• Identify any metrics trending in the wrong direction
• Flag new integration data flows for mapping review
• Check property creation log: how many new properties were created? By whom? Following conventions?

Quarterly (2 hours):

• Full property audit: identify unused, duplicate, and undocumented properties
• Review and update thresholds based on business changes
• Association completeness audit across all objects
• Report to leadership: data quality trend, remediation completed, risks identified

The quarterly review is where most governance programs start. It's also where most fail, because quarterly is too infrequent. The weekly check catches problems before they compound. The monthly review catches trends. The quarterly review is for structural changes and stakeholder reporting.

If you can only do one cadence, do monthly. It's the minimum viable frequency for catching decay before it becomes a crisis.

5. Escalation path

What happens when someone breaks the rules? A governance policy without consequences is a wish list.

Severity levels:

Level	Example	Response
Low	Property created without description	Owner adds description, sends naming convention reminder
Medium	Bulk import without approval that introduces duplicates	Owner schedules cleanup, documents impact, reviews import process with team
High	Integration configured without data mapping review that corrupts existing records	Immediate rollback if possible, incident review, process change

The escalation path isn't about punishment. It's about making the cost of ignoring governance visible. When a rogue import creates 500 duplicate contacts and someone has to spend 4 hours deduplicating them, that cost gets documented and shared. The next time someone wants to skip the import approval process, there's a concrete example of why it exists.

Most governance violations are low-severity and unintentional. A quick correction and a reminder is usually enough. The escalation path matters for the medium and high cases that erode trust in CRM data.

Encoding governance into the system

The best governance rules are the ones people can't break. HubSpot gives you several mechanisms for encoding rules into the system instead of relying on people to remember them.

Required fields on forms and record creation. If lifecycle stage must be set for every contact, make it required on the form. Don't write a rule saying "always set lifecycle stage" — make the system refuse to save without it.

Validation workflows. Build workflows that catch violations automatically. A contact created without a company association triggers a task for the data owner. A deal moved to "Closed Won" without an amount triggers an alert. A property with no updates in 90 days gets flagged for review.

Controlled vocabularies. Convert free-text fields to dropdown selects where values should be standardised. Industry, lead source, deal type — these should never be free text. Every free-text field is an invitation for inconsistency that no amount of policy documentation prevents.

Permission-based property creation. Restrict who can create custom properties in HubSpot. Not everyone needs that ability. Limiting creation rights to the property owner (from Section 1) is the simplest way to enforce the request process.

The property hygiene article covers how to implement these controls. The data quality dimensions article explains why consistency and validity matter at the measurement level. The governance policy just needs to state which controls are active and who maintains them.

Governance and AI readiness

If your team is evaluating Breeze AI features, data governance isn't optional prep work. It's a prerequisite. The research backs this up: 62% of organisations cite data governance as their biggest barrier to AI adoption, and Validity found that 45% of companies' CRM data isn't prepared for AI implementation. The barrier isn't the AI tools. It's the data they need to work with.

Every component of the AI readiness score maps to a governance failure mode. Low data completeness means required fields aren't enforced. Poor consistency means controlled vocabularies aren't in place. Broken associations mean nobody monitors relationship integrity. Low activity depth means CRM adoption governance is missing.

The AI governance article makes the case that data quality governance IS AI governance. This article gives you the policy structure to implement it.

Portals that score above 66 on AI readiness (Level 4: AI-Leveraging) almost always have some form of active data governance. Not necessarily a formal document, but named owners, enforced standards, and regular review cadences. The portals below 45 (Level 2: AI-Exploring) almost never do. The correlation isn't a coincidence.

Common governance mistakes

Starting with the policy instead of the audit. You can't write meaningful thresholds without knowing your current state. Run a data quality audit first. The audit tells you where you are. The policy defines where you're going and how you'll stay there.

Making the policy too long. If your governance document is longer than two pages, it won't get followed. Strip it to the five sections above. Detailed procedures (how to run a dedup, how to do a property audit) live in separate playbooks, not in the governance policy itself.

Governance without monitoring. A policy that says "duplicate rate must stay below 2%" means nothing if nobody measures the duplicate rate. Manual checks work for the first month. Then they stop. Automated monitoring (running continuously in the background) is what makes thresholds enforceable long-term.

Treating governance as a one-time project. I've watched teams spend two weeks building a governance framework, declare victory, and never revisit it. Six months later the portal is back where it started. Governance is an ongoing function, not a project with an end date. The review cadence from Section 4 is what makes the difference.

Frequently Asked Questions

What is data governance in HubSpot?

Data governance in HubSpot is the set of rules, ownership, and processes that determine who can create and modify CRM data, what standards that data must meet, and how compliance with those standards is monitored. It covers property naming conventions, data quality thresholds, review cadences, and escalation paths. Effective governance encodes rules into the system (required fields, validation workflows, controlled vocabularies) rather than relying on people to remember a policy document.

How do you start a data governance program for HubSpot?

Start with an audit, not a policy. Measure your current data quality dimensions — fill rates, duplicate rates, association coverage, property hygiene. Then assign a named owner (a specific person, not a team) and set thresholds for the metrics that matter most. Build the review cadence around monthly check-ins. The policy document comes last, after you know what you're governing and who's responsible.

How often should you review HubSpot data governance?

Weekly for alerts and property request approvals (5 minutes). Monthly for metric reviews and trend analysis (30 minutes). Quarterly for full property audits, threshold updates, and stakeholder reporting (2 hours). Monthly is the minimum viable cadence — anything less frequent and data decay compounds faster than you can catch it.

Why do CRM users fabricate data?

Validity's 2025 research found that 37% of CRM users regularly fabricate data to tell leaders what they want to hear. This happens when the CRM is unreliable enough that people stop trusting it (workers spend 13 hours per week on average just searching for basic information). When accurate data is hard to find, people fill in what sounds right instead. Data governance addresses this by making accurate data easier to find (through enforced completeness and organisation) and by setting thresholds that surface quality problems before trust erodes.

What's the difference between data governance and data quality?

Data quality is the state of your data: is it complete, consistent, valid, and current? Data governance is the system that maintains data quality over time: who owns it, what rules apply, how often it's reviewed, and what happens when standards aren't met. You can have a one-time data quality cleanup without governance, but the results won't last. Governance is what prevents the portal from decaying back to its pre-cleanup state.

Check your data governance baseline at hubhorizon.io — see your data quality score, property hygiene grade, and AI readiness level in under 5 minutes. Know where you stand before writing your policy. View pricing plans for continuous monitoring that keeps your governance standards enforceable.

Peter Sterkenburg is the founder of HubHorizon, a continuous portal health platform for HubSpot. He's seen enough governance documents gather dust to know that the ones worth writing are the ones short enough to follow and specific enough to enforce.