Your Enterprise HubSpot portal has a data governance problem — here's how to fix it

Your Enterprise HubSpot portal has a data governance problem — here's how to fix it

Enterprise HubSpot portals accumulate data fast but most teams have no retention policies, no deletion audit trail, and no compliance framework. A practical guide for RevOps teams.

Peter SterkenburgMarch 24, 202610 min read
Peter Sterkenburg

Peter Sterkenburg

HubSpot Solutions Architect & Revenue Operations expert. 20+ years B2B SaaS experience. Founder of NordScope.

I was reviewing an Enterprise portal recently. 500,000 contacts, 800 custom properties across 6 hubs, 40+ team members. The kind of portal where a misconfigured workflow can touch half a million records before anyone notices.

Their CISO asked three questions during a security review:

  1. What data do you retain, and for how long?
  2. What happens when we delete a user account?
  3. Can you prove it?

The RevOps lead had no answers. Neither did their HubSpot Solutions Partner.

I've seen this in every large portal I analyse. RevOps teams are brilliant at building pipeline workflows and optimising conversion rates. Data governance, though? The boring work of retention policies and deletion audit trails? That falls through the cracks until a CISO, a legal review, or a GDPR subject access request forces the conversation.

The compliance gap in RevOps

RevOps teams think about efficiency. CISOs think about risk. Enterprise portals sit between the two, full of business-sensitive data (deal values, contact history, pipeline forecasts) managed by a team that rarely thinks about regulatory compliance.

The research makes the scale of this problem concrete. According to Validity's 2025 State of CRM Data Health report, 44% of organisations estimate they lose over 10% of annual revenue due to poor CRM data quality. And IBM's Cost of a Data Breach 2024 report puts the average breach cost at $4.88M globally, $5.17M in the EU. For an Enterprise portal with hundreds of thousands of contacts, data governance isn't a nice-to-have. It's a financial risk.

Scale makes everything worse:

  • A portal with 500K contacts isn't just 10x bigger than one with 50K. It's 10x more liable under GDPR, because each contact is a data subject with rights.
  • When 40 people can access portal data, the question isn't whether someone will access the wrong portal. It's when.
  • Enterprise portals connect to Salesforce, Marketo, Clearbit, ZoomInfo. Each integration is a data processing relationship that needs governing.

If your organisation operates in the EU (or processes EU residents' data), GDPR isn't optional. It goes well beyond cookie banners. It's about how you handle CRM data from the moment it enters your portal to the moment you delete it. The ICO fined British Airways £20M for a data breach affecting 400,000 customers. Meta was fined €1.2 billion by the Irish DPC for transferring EU data to the US. These aren't abstract risks.

Every Enterprise CISO will eventually ask those three questions. If your RevOps team can't answer them, you have a governance gap.

What "data governance" actually means for HubSpot

When most RevOps teams hear "data governance," they think naming conventions and property hygiene. Those matter. They're the foundation. But Enterprise governance goes further.

Four things CISOs actually care about:

1. Retention — What data do you keep, and for how long? Is there a policy, or does everything accumulate forever?

2. Access control — Who can access which portal's data? Is ownership verified on every request, or just at login?

3. Deletion completeness — When someone deletes their account, what actually happens? Is every table cleaned? Are OAuth grants revoked?

4. Audit trail — Can you prove what happened? Who accessed what, when, and what changed?

Most data quality frameworks stop at the first two. Enterprise compliance requires all four. The rest of this article walks through each one, with the specific problems I've found in real portals and how we solved them.

Retention — the policy nobody writes

This is the first pillar, and the one most teams skip entirely.

This is what accumulates in a typical HubSpot analytics tool over time:

  • Analysis history — every health score snapshot, every diagnostic run
  • Write operations — every property edit, every bulk update, with before/after values
  • Activity logs — every login, every analysis trigger, every export
  • Pipeline cache — trend data for forecasting dashboards
  • Form analytics — submission patterns and conversion tracking

Without a retention policy, this data grows unboundedly. A portal that's been running for two years might have thousands of analysis snapshots that nobody looks at but everyone is liable for under GDPR Article 5(1)(e), which requires data to be "kept for no longer than is necessary."

The framework:

  1. Define retention periods per data type. Analysis history: 180 days. Write operations: 90 days. Activity logs: 90 days. Pipeline cache: 90 days.
  2. Make it configurable per portal. Enterprise customers need different retention for different data types. A financial services company may need 7-year retention on certain records; a startup may want 30 days.
  3. Enforce it automatically. A retention policy that exists on paper but isn't enforced is worse than no policy. It creates false confidence.

At PortalPilot, we built automated retention enforcement that runs daily. Portal owners set their retention periods in the dashboard. A scheduled job prunes data that exceeds those thresholds. Nobody has to remember to clean up.

That's retention. The second pillar is where things get more technical.

Access control — who can see whose portal?

Multi-tenant access control sounds simple until you think about it. A HubSpot Solutions Partner manages 30 client portals. A team member runs an AI analysis on Client A's portal. The system checks their subscription tier, they're paid, so the analysis runs. But did anyone verify they actually have access to Client A's portal?

In many tools, the answer is no. The tier check passes, and the analysis runs on data the team member shouldn't see.

Proper access control means verifying portal ownership on every API request, not just at login. Every single endpoint that touches portal data checks that the user is the portal owner or a verified team member. Behind that, Row-Level Security at the database layer enforces that User A cannot query User B's data, even if application code has a bug. And rate limiting per portal (not just per user) prevents one team member from exhausting API quota on a shared portal.

We hardened PortalPilot's access control across 20+ API endpoints in March 2026. Every function that accepts a portal ID verifies ownership before processing.

The third pillar is deletion. And this is where most tools quietly fail.

Deletion — what actually happens when you press "Delete"?

GDPR Article 17 gives data subjects the "right to erasure." For a CRM analytics tool, this means: when a user deletes their account, every trace of their data must be removed. Not just the profile row. Everything.

Most people don't realise how many things break when you try to do this properly:

OAuth grants persist after deletion. If you delete a user's encrypted tokens from your database but don't call HubSpot's revocation endpoint, HubSpot still shows your app as "connected" in their portal settings. The data processor relationship isn't terminated.

Security audit records don't cascade. A security_incidents table might store affected portal IDs as a UUID array, not a foreign key. Standard cascade deletion misses it entirely.

Login attempts are keyed by email, not user ID. Delete the user, and their failed login attempts, complete with email addresses, persist forever.

Complete deletion means:

  1. Revoke all OAuth grants with HubSpot
  2. Clean up security audit records (remove portal IDs from arrays, delete rows where the array becomes empty)
  3. Delete login and password reset attempts by email
  4. Delete data across 40+ database tables, not just the obvious ones

We rebuilt our account deletion flow to handle all of these cases. Not glamorous work. But it's the difference between "we deleted your account" and "we can prove we deleted every trace of your data."

The fourth pillar ties it all together.

Audit trail — proving what happened

An audit trail isn't just logging. It's the ability to answer "who did what, when, and to which portal" months after the fact. When a data quality audit uncovers unexpected changes, or a GDPR subject access request lands on your desk, the audit trail is what lets you respond with facts instead of guesses.

Write operation tracking needs before/after values. Not just "property changed" but "property X changed from 'Lead' to 'MQL' by User Y at timestamp Z." Activity attribution matters too: when a team member triggers an analysis on a shared portal, the activity log should record the team member, not the portal owner.

Then there's the logs themselves. Email addresses and personal identifiers need masking in log output. You need enough detail to investigate, but not so much that your logs become a second data liability. And audit logs need their own retention period. 90 days is reasonable: long enough for incident investigation, short enough to limit exposure.

The enterprise security checklist

If you're evaluating any tool that touches your HubSpot data, including PortalPilot, ask these questions:

  • Does it verify portal ownership on every API request (not just at login)?
  • Is customer data encrypted at rest and in transit?
  • What happens when I delete my account? Are OAuth grants revoked?
  • Does it have configurable data retention policies?
  • Are retention policies enforced automatically or just documented?
  • Where is the data stored? Which country? Which provider?
  • Does AI processing stay within the EU?
  • Is individual record data stored, or only metadata and aggregate scores?
  • Is there an audit trail for write operations?
  • Can I get a DPA (Data Processing Agreement)?
  • What's the incident response process and notification timeline?

If the tool can't answer all of these, it's not ready for Enterprise HubSpot portals.

At PortalPilot, every one of these is implemented and documented on our security page. We built this because the portals we want to analyse are the big, complex ones. The ones where CISOs ask hard questions. Getting those portals means earning trust first.

Frequently Asked Questions

What does GDPR Article 17 mean for HubSpot tools?

Article 17 (right to erasure) means that when a user requests deletion, every piece of their personal data must be removed. For a tool connecting to HubSpot via OAuth, this includes revoking the OAuth grant, deleting stored tokens, removing analysis results, cleaning audit records, and purging login attempts. A simple database row deletion is not sufficient.

Do I need a DPA with every tool that connects to my HubSpot portal?

If the tool processes personal data from your portal — including contact names, email addresses, and deal values — then yes. Under GDPR Article 28, you need a Data Processing Agreement with every data processor. Tools that only analyse property metadata without accessing individual records have a narrower processing scope, but a DPA is still recommended.

How long should I retain CRM analytics data?

GDPR requires data to be kept "no longer than is necessary" (Article 5(1)(e)). In practice: 90 days for operational data like logs and cache, 180 days for analytical data like health score history, and configurable per-portal overrides for organisations with specific regulatory requirements. The key is having a defined, enforced policy — not just a document.

What is the difference between data governance and data quality?

Data quality covers accuracy, completeness, and consistency of your CRM records. Data governance is the broader framework: who owns the data, how long you keep it, who can access it, and how you prove compliance. You can have excellent data quality and still fail a GDPR audit without a retention policy, deletion process, or audit trail.

Does PortalPilot store individual contact or deal records?

No. Record samples (up to 1,000 per object type) are processed transiently in memory to compute fill rates and health scores. Individual records are never written to the database. Only property metadata (names, types, configuration) and aggregate scores are stored. See the security page for the full data handling breakdown.


Start your free portal health check at portalpilot.io

View pricing plans

Peter Sterkenburg is the founder of PortalPilot by NordScope, building CRM health intelligence for HubSpot from Finland. He has analysed hundreds of HubSpot portals across mid-market and enterprise organisations, specialising in data quality, RevOps maturity, and the operational challenges of scaling CRM at speed.