- Data governance fails when nobody owns it. Assign a single owner - usually RevOps - with the authority to set standards, enforce policies, and say no to bad process.
- The governance gap is not inside your CRM. It is in the spaces between tools: shared drives, exported CSVs, enrichment platforms, agency handoffs, and the laptops of people who have already left.
- A working governance framework is five things: documented ownership, written policies that cover the full data lifecycle, vendor accountability, cross-team sharing rules, and a plan for when people leave.
Here is a question most revenue teams cannot answer cleanly: who owns your prospect data?
Not who uses it. Not who imported it. Not who pays for the enrichment credits. Who is responsible for it - for its accuracy, its access controls, its lifecycle, and its compliance posture?
In most organisations, the honest answer is nobody. Sales owns the outreach. Marketing owns the lead forms. Ops owns the CRM. Finance owns the vendor contracts. But the data itself - the actual records, where they live, who can touch them, and what happens to them - sits in a gap between all of those teams.
That gap is where governance should be. And in most revenue organisations, it is empty.
This is not a guide to CRM hygiene or data cleaning. Those are covered elsewhere. This is about the organisational framework around your prospect data - who owns it, what the rules are, and how to make sure the rules are followed when there are dozens of people, multiple tools, and data flowing in every direction.
Why governance keeps getting skipped
Governance is easy to deprioritise because the consequences of not having it are slow and invisible.
Nobody gets fired because a retention policy does not exist. No deal falls through because export logs are not being kept. No board meeting gets derailed because a departing SDR took a CSV with them.
Until one of those things does happen - a subject access request you cannot fulfil, a data breach you cannot scope, a compliance audit you cannot pass, or an ex-employee’s prospect list showing up at a competitor - and then the absence of governance becomes the most expensive problem on the board.
The reason it gets skipped is not that people think it is unimportant. It is that the cost is invisible today and the payoff is preventing something that might happen tomorrow. That is a hard sell when the team has pipeline targets to hit this quarter.
But governance does not have to be heavy. The framework below is five components. Most of them can be set up in a week and maintained with less effort than the workarounds teams are already using.
Component 1: Assign a data owner
Everything starts here. If nobody owns the data, nobody governs it.
The data owner is the person who is accountable for how prospect data is sourced, stored, shared, used, and retired across the revenue team. This does not mean they do all of the work. It means they set the standards, make the decisions, and have the authority to enforce them.
In most organisations, the natural home for this is RevOps. They already sit across sales, marketing, and customer success. They already manage the CRM. They already deal with the consequences of bad data. Giving them formal ownership of the governance layer is usually a small step from what they are already doing informally.
What the data owner needs to define:
What counts as prospect data. Not just CRM records - also enrichment outputs, exported CSVs, saved lists, browser extension captures, and any dataset that contains names, emails, phone numbers, or company identifiers.
Where it is allowed to live. Which systems are sanctioned for storing prospect data? The CRM, your data platform, and your sequencer might be approved. Shared Google Sheets, personal laptops, and WhatsApp threads are not.
Who can do what. Not just CRM permissions - but who can export data, who can share it externally, who can upload new lists, and who can delete records.
What the lifecycle looks like. How data enters the system, how long it stays, and what triggers its removal or archival.
Without a data owner, these questions get answered ad hoc by whoever is moving fastest. That is not governance - it is improvisation.
Component 2: Write the policies down
Unwritten rules are not rules. They are habits that work until someone new joins the team, someone senior overrides them, or someone simply did not know they existed.
Governance policies do not need to be long. They need to be specific, accessible, and enforced. A one-page document that the team actually reads is worth more than a 30-page policy manual that nobody has opened since it was written.
The policies most revenue teams need to document:
Data sourcing policy
Where is the team allowed to source prospect data from? Purchased lists, enrichment platforms, LinkedIn, webinar platforms, conference apps, and referrals are all different sources with different quality levels and different compliance implications. The policy should name the approved sources and the process for adding new ones.
Data sharing policy
Who can share prospect data, with whom, and in what format? Can reps email CSVs to agency partners? Can marketing share enriched lists with event sponsors? Can a hiring manager send candidate data to a recruiter? Each of these is a data sharing event that needs a rule - not because you want to slow people down, but because once data leaves your governed environment, you lose control of it.
Data export policy
Who can export prospect data from the CRM or data platform, and under what conditions? Are there limits on export size? Are exports logged? Do exports require approval above a certain row count? Export is the point where governed data becomes ungoverned. The policy should treat it accordingly.
Vendor data policy
When you buy data from a vendor or use a third-party enrichment provider, what are the terms? Can you store the data indefinitely or does the contract limit retention? Can you share vendor-sourced data with partners or agencies? Are there restrictions on how it can be used? Most vendor contracts include data usage clauses that teams never read and frequently violate. The policy should translate those clauses into rules the team can follow.
Data retirement policy
What triggers the removal or archival of prospect data? Common triggers include: the prospect opted out, the record has not been updated in a defined period, the campaign it was sourced for has ended, the vendor contract has expired, or the legal retention period has passed. The policy should name the triggers and define what “removal” means - deleted, anonymised, or archived with restricted access.
Component 3: Govern the spaces between tools
Most teams focus governance on the CRM because that is the system they can see. But the biggest governance gaps are not inside the CRM. They are in the spaces between tools.
Exported files
The moment a list is exported to CSV, it exits every access control, audit log, and retention policy your CRM provides. It becomes a file that can be copied, emailed, uploaded to a personal drive, or forgotten on a laptop. Governance needs to account for what happens to exports after they leave the system - not just the act of exporting.
Enrichment platforms
When you enrich data through a third-party platform, a copy of your prospect data now exists in that platform. What are the retention terms? Can the provider use your data to improve their own database? What happens to the data if you cancel the contract? These are governance questions that most teams never ask.
Shared drives and collaboration tools
Prospect lists in Google Drive, contact data in Notion, lead lists in Slack channels - these are all ungoverned data stores. They have no access controls beyond whatever the team happened to set, no audit trail, and no retention policy. If prospect data lives in these places (and it almost certainly does), governance needs to either bring it back into a governed system or set explicit rules for how it is handled.
Agency and partner handoffs
If you share prospect data with an agency, a consultancy, or a channel partner, you are extending your data footprint beyond your organisation. The governance framework needs to cover what data can be shared, in what format, under what terms, and what the partner is required to do with it when the engagement ends. A data processing agreement is the legal mechanism, but the operational rules need to be clear to the people actually sharing the files.
Component 4: Make vendors accountable
Revenue teams rely on multiple data vendors - enrichment providers, intent data platforms, list brokers, verification services. Each vendor has their own data sourcing practices, accuracy standards, and compliance posture.
Most teams evaluate vendors on coverage and price. Few evaluate them on governance.
Questions to ask every data vendor
Where does your data come from? Legitimate vendors should be able to explain their sourcing methodology. If the answer is vague, the data provenance is likely weak.
What is your data accuracy and freshness commitment? Not a marketing claim - a contractual commitment. What recourse do you have if the data is materially inaccurate?
What are the retention and usage terms? Can you store the data indefinitely? Are there restrictions on how you can use it (outbound only, no resale, specific geographies)? What happens to data you have already downloaded if you cancel the contract?
How do you handle subject access and deletion requests? If a prospect contacts the vendor and asks for their data to be deleted, does that cascade to you? Are you notified? Is there a process?
Are you compliant with GDPR, PECR, and relevant regulations? Not just “we take compliance seriously” - do they have documented evidence? A DPA? A named DPO?
The answers to these questions should be documented and reviewed annually. Vendor accountability is a governance function, not a procurement function.
Component 5: Plan for when people leave
This is the governance control most teams discover they need only after it is too late.
When a team member leaves - a rep, an SDR, an ops manager, an agency contractor - their access to your systems gets revoked. But revoking access is not the same as recovering data.
What offboarding needs to cover
Identify all data the person had access to. Not just their CRM login - every export they ran, every list they built, every file they downloaded, every enrichment tool they used with their own credentials.
Recover or confirm deletion of local files. If the person downloaded CSVs to their laptop, those files need to be recovered or confirmed deleted. This is especially important for remote employees using personal devices.
Revoke third-party tool access. If the person had credentials for enrichment platforms, sequencers, or data tools, revoke them. If they used personal logins, confirm that any data stored under those accounts is removed.
Reassign ownership of shared resources. Lists, campaigns, saved searches, and CRM views owned by the departing person need to be reassigned - not left orphaned.
Audit recent activity. Review the person’s export history and data access for the final 30 to 90 days. This is not about suspicion - it is about confirming that nothing needs follow-up.
This sounds like a lot of work. It is significantly less work when export logs exist, access is role-based, and data lives in governed systems rather than personal files. In other words, it is significantly less work when you have governance.
What a working governance framework looks like day-to-day
When governance is in place, the day-to-day experience for the team does not feel bureaucratic. It feels clearer.
Reps know where to source data and where not to. They know what they can export and what needs approval. They do not build shadow spreadsheets because the governed system gives them what they need.
Managers can see who is using data, how much they are using, and whether usage patterns match active campaigns. They do not get surprised by credit overages or rogue exports.
Ops can respond to a subject access request in minutes instead of days, because they know where the data lives and who touched it. They can offboard a team member without a scramble, because exports are logged and access is role-based.
And when a compliance question comes up - from a prospect, a client, a partner, or a regulator - the answer is documented, not reconstructed.
Getting started
You do not need to build the entire framework at once. Start with the component that addresses your biggest current risk.
If you have no idea who has exported what, start with export tracking. If data lives in a dozen ungoverned locations, start by consolidating into a system with access controls. If people are leaving and taking data with them, start with an offboarding checklist. If vendor contracts are unreviewed, start with a vendor audit.
One component, implemented properly, is worth more than five components documented but not enforced.
The goal is not perfection. It is to move from a state where nobody knows who owns the data and nobody tracks what happens to it, to a state where ownership is clear, rules are written, and the team operates within a structure it can actually follow.
DataFixr provides the operational layer for prospect data governance - role-based access, export audit trails, credit tracking, and retention controls in a single workspace. So governance is built into how your team works with data, not bolted on after. Request early access ->