The Complete Guide to HubSpot Data Protection

Protecting HubSpot data means four things working together: controlling who can access and change it, having an independent backup that can restore it if something goes wrong, meeting the regulatory obligations that apply to your data (GDPR, SOC 2, HIPAA), and being able to detect and investigate incidents when they happen. HubSpot secures the infrastructure your data lives on (encryption, hosting, certifications), but the configuration of all four of these areas is the customer’s responsibility under HubSpot’s Shared Responsibility Model. This guide covers each in depth, with links to detailed guides on backup and recovery scenarios specifically.

Search for “HubSpot data protection” and most of what comes back is really about one thing: backup. Backup matters, but treating “data protection” as a synonym for “backup” misses most of what actually determines whether an organization’s HubSpot data is safe.

Consider four scenarios, all of which we could reasonably call “HubSpot data protection failures”:

A former employee, whose access wasn’t revoked promptly, deletes a segment of records on their way out. A misconfigured automatic-deletion privacy setting quietly removes contacts that were dormant but valuable. An attacker who phished a Super Admin’s credentials spends a week inside the account before anyone notices anything unusual. A company storing patient intake information in HubSpot discovers, during a compliance audit, that they were never covered by a Business Associate Agreement in the first place.

Only one of these is really “solved” by having a backup. The others are about who can do what (access control), what gets logged and who’s watching (visibility), and what HubSpot has and hasn’t agreed to be responsible for (compliance posture). A genuinely complete approach to HubSpot data protection has to address all four:

1. Access control: who can view, edit, export, or delete data, and how tightly that’s scoped to what each person actually needs.
2. Visibility: what’s logged, who’s reviewing it, and whether unusual activity would actually be noticed.
3. Backup and recovery: an independent copy of your data that exists outside HubSpot’s environment, with the ability to restore to a specific point in time.
4. Compliance posture: understanding precisely what HubSpot has certified, contracted, and agreed to regarding your data, and what remains entirely your responsibility.

Each of these is a section in this guide. They’re not independent of each other. weak access control makes backup more important (because more things can go wrong), and a strong compliance posture depends on the first three being in place and demonstrable. But each also requires different tools, different settings, and different people paying attention to it. This guide walks through all four, with backup and recovery condensed here and covered in full depth in our companion guide, How to Back Up HubSpot CRM.

If there’s one idea this entire guide rests on, it’s this: HubSpot secures the platform. You configure and govern what happens inside it. This isn’t a loophole or fine print; it’s the explicit, written basis on which HubSpot’s certifications, agreements, and terms operate, and understanding precisely where the line sits is the foundation for everything else in this guide.

What HubSpot Has Actually Certified and Agreed To

HubSpot’s security program includes real, independently-audited certifications: SOC 2 Type II and SOC 3 reports (the SOC 3 report is available with no NDA required through HubSpot’s Trust Center), and ISO 27001 certification for its information security management system. HubSpot’s Data Processing Agreement covers GDPR terms, subprocessor commitments, breach notification timelines, and international transfer mechanisms.

These are meaningful, and they cover real things: how HubSpot secures its infrastructure, how it handles a security incident on its end, how data moves across borders, and what happens if HubSpot itself experiences a breach. If you’re evaluating HubSpot from a security/compliance standpoint, these documents are the right starting point.

What These Certifications Don’t Cover

Here’s where the line sits, and where most confusion happens: HubSpot’s certifications describe how HubSpot runs HubSpot. They don’t describe how you’ve configured your account.

A SOC 2 Type II report covers HubSpot’s own information security policies, access controls, encryption standards, incident response procedures, and change management as a company. It says nothing about whether your HubSpot portal has forty Super Admins, whether your sales team’s export permissions are scoped appropriately, or whether your organization has a tested process for what happens when your data is accidentally deleted.

If your organization needs to demonstrate its own SOC 2 compliance, as many B2B SaaS companies and their vendors increasingly do, HubSpot’s SOC 2 report doesn’t transfer to you. It’s evidence that your subprocessor (HubSpot) is well-controlled. Your own SOC 2 audit will still examine how you’ve configured access, retention, and monitoring within that subprocessor’s platform. These are related but genuinely separate things, and conflating them is one of the most common mistakes organizations make when reasoning about their compliance posture.

The HIPAA Question, Specifically

Few areas illustrate the Shared Responsibility Model more precisely than how HubSpot handles HIPAA and Protected Health Information (PHI). It’s an area where getting the details right matters enormously, because the consequences of getting it wrong are regulatory, not just operational.

The accurate picture: HubSpot can support HIPAA-covered data, but only under specific, opted-into conditions. As well, the coverage is narrower than “HubSpot is HIPAA compliant” would suggest.

Specifically:

• Sensitive Data and Highly Sensitive Data properties: The feature framework that enables HIPAA-relevant handling is available only on Enterprise-tier subscriptions. On Starter or Professional, this framework doesn’t exist at all.

• A Business Associate Agreement (BAA) is built into HubSpot’s Sensitive Data Terms, but it only takes effect if the customer actively turns on Sensitive Data, selects the Health/Medical Data category, and checks a box self-identifying as a HIPAA Covered Entity or Business Associate. Skip any of these steps, and no BAA is in place; even on an Enterprise account that’s otherwise eligible.
• Even with the BAA active, coverage is scoped to specifically designated “Covered Services.” HubSpot’s terms define “Permitted Sensitive Data” and explicitly distinguish it from “Prohibited Sensitive Data”, any use of PHI outside the designated scope isn’t protected by the BAA and can violate HubSpot’s terms of service regardless of whether a BAA exists on the account.
• The customer bears explicit, contractual responsibility for compliance assessment. HubSpot’s Sensitive Data Terms state directly that customers are responsible for assessing whether their use of the service meets their compliance obligations, for managing sensitive data within their account, and for handling data subject access requests.

The practical takeaway for any organization that stores, or is considering storing, health-related information in HubSpot: don’t assume coverage exists by default, don’t assume Enterprise alone is sufficient, and don’t assume that opting in covers every feature uniformly. If PHI is involved, this is a conversation to have explicitly with whoever manages your HubSpot account configuration and your compliance/legal function before data goes in, not after.

One more dimension worth flagging now and returning to later: even in an account where the BAA is properly active for live data, nothing in HubSpot’s Sensitive Data Terms suggests that ancillary processes are themselves “Covered Services” under the BAA. For example, the native Backup & Restore tool’s CSV exports, or third-party backup integrations. An organization handling PHI under a properly-configured BAA should not assume that a backup or export of that data inherits the same protections automatically. We’ll return to this when discussing backup and compliance together later in this guide.

The One-Sentence Summary

If you remember nothing else from this section: HubSpot’s certifications are real, and they cover HubSpot. Everything about how your specific account is configured, like who has access, what’s backed up, how long data is retained, and whether compliance frameworks are properly activated, is yours. The rest of this guide is about that second category.

If the Shared Responsibility Model establishes that configuration is your job, access control is where that job most concretely begins. Look back at the data loss scenarios from our companion piece, 5 Ways HubSpot Data Gets Lost; the departing employee with lingering access, the bulk delete that went further than intended, even the ransomware scenario that starts with compromised Super Admin credentials. Every one of them is, at its root, an access control problem as much as anything else. Get access control right, and you don’t just prevent unauthorized access; you shrink the blast radius of almost every other failure mode in this guide.

The Super Admin Sprawl Problem

This is, by a wide margin, the most common access control issue in HubSpot accounts. It’s largely a byproduct of HubSpot’s own historical pricing structure. For years, granular permission sets (the ability to create custom roles with precisely scoped access) were available only on Enterprise plans. For everyone else, the practical choice was binary: either a user was a Super Admin, with unrestricted access to billing, integrations, user management, and every object in the account, or they had a more limited standard role that often didn’t map well to what they actually needed to do.

The result, well-documented in HubSpot’s own community: in small and mid-sized accounts especially, it’s common to find the large majority of users (sometimes 90% or more) set as Super Admins, not because they need that access, but because it was the path of least resistance when someone needed something they didn’t have.

HubSpot’s own recommendation is blunt on this point: every portal needs at least one Super Admin, but more than a small handful represents unnecessary risk. HubSpot’s security guidance suggests as few as two to five for most organizations. Super Admins have unrestricted access, including billing, integrations, and user management; every additional Super Admin is another account that, if compromised, gives an attacker the keys to everything. HubSpot’s Security Health Score, available to all accounts, directly penalizes having too many Super Admins, making this one of the few access control issues that’s both common and easy to measure without specialized tooling.

If you do nothing else after reading this section: go to Settings > Users & Teams, sort by permission level, and count your Super Admins. If the number surprises you, you’ve just identified your highest-leverage access control fix. It’s one that requires no purchase, no new tooling, and can typically be done in an afternoon.

The 2026 Seat-Based Model: A Practical Tool for Access Hygiene

HubSpot’s move to a seat-based pricing model (Core, Sales, Service, and View-Only seats, with permissions configured on top of each) is primarily a pricing and licensing change, but it has a meaningful side effect for access control that’s worth understanding even if you’re not the person managing the HubSpot contract.

View-Only seats are free and unlimited. This matters more than it might initially seem: it means there’s no longer a cost-based incentive to give someone a fuller seat “just so they can look at things.” Executives, auditors, contractors who need visibility but not edit access, and anyone in a “stakeholder” rather than “operator” role can have exactly the access and visibility they need without being provisioned with edit, export, or delete capabilities they don’t need and that represent pure downside risk if their credentials are ever compromised.

The broader principle here, sometimes called least-privilege access: every permission a user has that they don’t actually need to do their job is pure risk with no corresponding benefit. It doesn’t make them more productive. It only exists as a larger attack surface and a larger blast radius if their account is compromised or if they make a mistake. The View-Only seat tier removes the most common excuse for over-provisioning for an entire category of users.

Permission Sets, Teams, and Building Roles That Mirror Your Org

For Enterprise accounts, HubSpot’s permission sets allow building custom roles once and assigning them to multiple users. This is essentially the “real” version of role-based access control. Combined with Teams (which can be structured by department, region, or function), users can be set up to automatically inherit appropriate access based on where they sit in the organization, rather than having permissions configured one user at a time.

A few practical patterns worth establishing, regardless of company size:

• Build roles around what people do, not around convenience. A marketing team member who builds and sends campaigns needs different access than a marketing leader who needs visibility across the whole funnel but rarely edits records directly. Collapsing both into “Marketing, full access” because it’s faster to set up once creates exactly the over-provisioning problem described above.

• Separate “can use the tools” from “can configure the account.” HubSpot’s permission model distinguishes account-level settings (billing, integrations, authentication, domain settings, user management itself) from day-to-day CRM usage. The number of people who need the former should be a small fraction of the people who need the latter. Someone can be excellent at running campaigns or managing a pipeline without ever needing access to billing or integration settings, and giving them that access anyway doesn’t help them do their job better.
• Restrict bulk-action permissions specifically. Several of the data loss scenarios in our companion pieces (the bulk delete that goes further than intended, the bad import that overwrites thousands of records) require bulk delete or bulk edit permissions to happen at all. These permissions are exactly the kind of access that should be scoped to a small number of people who understand the risks, rather than enabled broadly because it’s occasionally useful.

SSO, and Why Enforcing It Matters More Than It Sounds

HubSpot supports SAML-based single sign-on with major identity providers (Okta, Azure AD, OneLogin), with the ability to require SSO for all users, with configurable exemptions for continuity planning (so an account doesn’t get permanently locked out if an identity provider has an outage).

The practical case for enforcing SSO, beyond the general security benefits, is that it centralizes deprovisioning. Recall the “departing employee” scenario from 5 Ways HubSpot Data Gets Lost. The core vulnerability was the gap between “employee gives notice” and “employee’s access is fully revoked across every system.” When HubSpot access is tied to SSO, revoking access in the identity provider revokes HubSpot access too, immediately, as part of the same action that revokes access to email, file storage, and everything else. Without SSO, HubSpot access must be revoked as a separate step. That’s one more thing that can be forgotten, delayed, or missed during a departure, especially a contentious one.

SCIM-based provisioning (supported through Okta) extends this further, automating not just deprovisioning but onboarding and role changes, so that someone’s HubSpot access automatically reflects their current role in the identity provider, without a manual step to keep it in sync.

The New Frontier: Breeze AI Permissions

As of 2026, HubSpot’s AI capabilities (branded Breeze) have their own permission layer, managed separately from standard user permissions. This is worth specific attention precisely because it’s new enough that many existing HubSpot governance practices haven’t caught up to it yet.

The relevant controls: admins can configure object-level AI scopes. For example, allowing Breeze to read Contact and Ticket data for generating summaries while explicitly blocking it from reading Deal or Revenue data. Separately, Breeze Intelligence permissions control who can use enrichment credits to pull third-party data into the CRM. And AI-specific audit logs let Super Admins see which users are prompting Breeze and what data the AI is surfacing in response.

Why this matters for data protection specifically: AI features that can read across your CRM (even just to generate a summary) are, from an access-control standpoint, another category of “who can see what” A support rep who couldn't previously see Deal/Revenue data directly might be able to get a summary that includes information from those fields if Breeze has been given broad read access and the rep can prompt it. This isn’t a flaw in Breeze. It’s simply a new permission surface that needs the same “what does this role actually need” thinking applied to it as every other permission in this section. Given how recently this layer was introduced, it’s worth an explicit review even for organizations that consider their broader permission structure well-established. “We set up roles two years ago” doesn't account for a permission layer that didn’t exist two years ago.

Security Health Score: The Practical Starting Point

HubSpot provides a Security Health Score, accessible to all accounts, that surfaces concrete, actionable findings. These include the Super Admin count discussed above, inactive user accounts that still have active access, two-factor authentication adoption, and other access-related signals.

The reason this is worth highlighting specifically: most of what's discussed in this section requires some judgment, such as what roles make sense for your org, how to structure Teams, or whether SSO enforcement fits your operational reality. The Security Health Score is different. It’s a checklist that doesn't require judgment to interpret, doesn’t require new tooling to access, and directly surfaces several of the highest-leverage issues covered above. For an organization that hasn’t done an access control review recently, checking this score and acting on what it surfaces is the lowest-effort, highest-signal starting point available.

If access control is about limiting what can happen, audit logs and visibility are about knowing what did happen. Every scenario in our companion piece, 5 Ways HubSpot Data Gets Lost, eventually reaches a moment where someone needs to answer the question “what changed, when, and who did it?” The honest truth is that for most HubSpot accounts, that question is harder to answer than people assume, and the answer depends heavily on subscription tier in ways that aren’t always obvious until you need the data.

What HubSpot’s Audit Logs Actually Capture, and the Tier Gap That Matters

HubSpot provides a centralized Audit Logs page (Settings > Account Management > Audit Logs) that records the creation, deletion, and update of user actions. The depth of what’s recorded differs dramatically between subscription tiers, in a way that directly affects how useful the logs are for investigating exactly the scenarios this guide is concerned with.

Available on Starter and Professional: logins (including mobile app logins), security activity, consent banner text updates, content activity (with retention varying by Content Hub tier), and CRM object activation, deactivation, and renaming. Notably, CRM record views are tracked at every tier, which is useful for understanding who’s been looking at what, even on lower tiers.

Enterprise-only: this is where the gap becomes significant for data protection purposes specifically. Property updates and property value updates (the actual record of what a field’s value was changed to and from) are Enterprise-only. So are workflow changes, pipeline changes, CRM object associations and association definition changes, list changes, and sensitive property value access.

Think back to Scenario 2 in 5 Ways HubSpot Data Gets Lost: the workflow that quietly corrupts data overnight. On an Enterprise account, the audit log can show you exactly which workflow ran, when, what property values it changed, and on how many records. On a Starter or Professional account, none of that is available through audit logs at all. You’d know that records changed (if you noticed at all) but not definitively what changed it, without relying on per-record Property History (where available) rather than an account-wide investigative tool.

This is a genuinely important piece of information for any organization on Starter or Professional evaluating their data protection posture: the tooling to investigate “what happened” after an incident is itself gated behind Enterprise, in addition to the recovery tooling (“Seamlessly Restore CRM Data,” also Enterprise-only) discussed in our backup guide. For non-Enterprise accounts, this raises the stakes on prevention (Section 2) and independent backup (Section 4) considerably. There’s less of a safety net on either side.

The 30-Day Default Window and Why Notifications Matter More Than the Log Itself

By default, the centralized audit log views (All Logs, Login History, and Security Activity) show the last 30 days. Security Activity History can be exported covering the last year, and login history specifically can be reviewed and exported for up to a year as well. But the default, at-a-glance view is 30 days.

This creates a specific risk that maps directly onto the “detection lag” problem described in “5 Ways”: if a problem isn't discovered within 30 days, the default view of the audit log won't show it. You’d need to know to look further back and export a longer range, which presumes you already suspect something happened in that window. For slow-burn issues (a departing employee’s actions discovered months later, a misconfigured retention policy that’s been quietly removing contacts for longer than anyone noticed) the default audit log view is the wrong tool, even though the underlying data may still exist in an export.

This is where audit log notifications become genuinely valuable, and they're available to Super Admins at no additional tooling cost: HubSpot can send an email notification when a high number of exports occur in a single day, or when a user’s admin permissions are removed. These two specific triggers map directly onto two of the highest-risk scenarios in this guide. The first covers a compromised account or departing employee attempting to exfiltrate data via bulk export. The second covers an unauthorized change to admin permissions. Setting these up takes a few minutes and turns “we'd only find out if someone happened to check the audit log” into “we'd get an email.”

Property History: The Per-Record Alternative

Even on accounts without Enterprise-level audit logs, Property History (viewable on individual records) can show what a specific field's value used to be, who changed it, and when. This was referenced in our companion guide on The Hidden Risk in Every HubSpot Import as part of the (labor-intensive) manual process for reconstructing data after a bad import.

The honest assessment: Property History is genuinely useful for investigating a specific, already-identified record or field. It is not a substitute for an account-wide audit log when the question is “which records were affected, and by what.” Answering that question by checking Property History one record at a time across a large dataset is exactly the kind of “operationally catastrophic” process described elsewhere in this guide, even when the underlying data technically exists.

Visibility Into HubSpot’s Own Access to Your Account

One audit log capability worth specific attention, because it’s often overlooked entirely: HubSpot employees (account managers, support specialists, engineers troubleshooting issues) have limited access to customer accounts by default, and that access is itself logged and exportable. Super Admins on any tier can export the last 90 days of HubSpot employee logins, broken down by department (Engineering, Account Management, Services, Customer Support, Sales, Product/UX), with timestamps for each instance.

This matters for two reasons. First, it’s a genuinely useful piece of the Shared Responsibility Model made concrete. It’s one of the few places where “what is HubSpot, as a company, doing inside our account” is directly answerable rather than something you have to take on trust. Second, for organizations with strict data access requirements (certain compliance frameworks require knowing and documenting who has accessed regulated data, including the vendor's own staff), this export is the mechanism for demonstrating that.

What “Good” Visibility Looks Like in Practice

Pulling this section together into something actionable: a reasonable visibility posture, achievable without third-party tooling, looks roughly like:

• Audit log notifications enabled for multiple exports and admin permission removals (a few minutes, any tier)

• A periodic (monthly or quarterly) review of the Security Activity export, not just the 30-day default view, which is particularly important on accounts without Enterprise's deeper property-level logging
• For Enterprise accounts: periodic review of property value changes and workflow modification logs, especially after any significant automation changes
• Awareness of, and periodic review of, HubSpot employee access history, which is particularly relevant if your account handles Sensitive Data under the frameworks discussed in Section 1

None of this recovers anything on its own. What it does is shrink the gap between “something went wrong” and “we know something went wrong,” which is the precondition for everything else in this guide, including backup and recovery, being useful at all. A perfect backup strategy is far less valuable if an incident goes undetected for months before anyone thinks to use it.

Backup and recovery is the area of HubSpot data protection most directly within your control, least dependent on subscription tier for the correct solution (even though, as covered above and in our other guides, several native tools are tier-gated), and the subject of our most detailed companion guide. Rather than repeat that material here, this section summarizes the core findings and connects them to the access control and visibility foundations covered in Sections 2 and 3.

The Shared Responsibility Model, Applied to Backup

Section 1 established the general principle: HubSpot secures the platform, you configure what happens inside it. Applied to backup specifically, this means: HubSpot’s infrastructure-level backups exist to restore HubSpot's platform in the event of a server-level disaster. They do not, and were never intended to, recover your individual records, configuration, or data after the kinds of incidents (bad imports, workflow errors, bulk deletions, departing employees, ransomware) covered throughout this guide.

Native Tools: A Quick Recap

HubSpot provides three native mechanisms, each with real but bounded value:

The native Backup & Restore tool exports CRM objects as CSV files, but doesn’t preserve associations between records, doesn’t include engagement history, doesn’t capture workflows or configuration, and produces files that expire after 14 days. Automated scheduling exists only on Enterprise.

The Recycle Bin retains deleted records for 90 days with Super Admin-initiated restoration. It’s genuinely useful for individual accidental deletions, but irrelevant to overwritten (rather than deleted) data, and bypassed entirely by permanent deletions (including the GDPR/privacy-related permanent deletions discussed in Section 5).

Manual CSV exports capture property values for selected records and fields, but miss associations, engagement history, workflows, forms, pipelines, reports, and custom property definitions, and depend entirely on someone remembering to run them.

“Seamlessly Restore CRM Data,” HubSpot’s newer Enterprise-only feature, allows reverting CRM record changes within the last 14 days, capturing the last 20 versions of record data (45 for contacts). It’s a meaningful improvement for the specific case of recent, identified bad changes. However, the 14-day window, Enterprise requirement, and the fact that restored records don’t automatically re-enroll in workflows all limit how far it goes.

Why Ransomware Changes the Calculus

The most important development covered in our backup guide is the shift in how ransomware operates: rather than simply encrypting data and demanding payment, current ransomware tactics (documented by Google Cloud's Threat Horizons research and Microsoft's tracking of the Storm-0501 threat actor) specifically target and destroy backup and recovery infrastructure before encrypting or exfiltrating the primary data. The logic is direct: an organization that can recover independently has no reason to pay, so destroying that option first maximizes leverage.

This connects directly back to Section 2’s access control discussion. If an attacker compromises a Super Admin account (the scenario Section 2 spent considerable effort on preventing) and your “backup” is a CSV export sitting in a shared drive, or a backup tool authenticated through that same HubSpot account, the attacker can reach and destroy it just as easily as the live data. A backup that lives inside the same access boundary as the system it protects isn't a separate recovery path.

What a Complete Solution Needs to Do

Our backup guide develops this into an eleven-point framework, covering automated scheduling, full and incremental backups, association preservation, point-in-time restore, encryption, independent storage (the ransomware-resilience point above), multi-person approval for destructive actions, multi-factor authentication on the backup console itself, compliance-grade retention, multi-tenancy for organizations managing multiple portals, and flexible storage options.

The throughline connecting this framework to the rest of this guide is that backup is the layer that catches everything the first three sections couldn’t prevent or didn’t catch in time. Strong access control (Section 2) reduces how often something goes wrong. Good visibility (Section 3) reduces how long it takes to notice. Backup (this section) determines whether, once noticed, it can actually be fixed, and how completely.

For the full treatment (including the detailed ransomware research, the complete eleven-point framework, and a comparison of how leading third-party solutions measure up against it) see How to Back Up HubSpot CRM and Best HubSpot Backup Solutions Compared. (Coming Soon)

Sections 1 through 4 established the building blocks: the Shared Responsibility Model, access control, visibility, and backup. This section is about how those building blocks come together, or fail to, when measured against specific regulatory frameworks. The throughline across all of them is the same one from Section 1: HubSpot provides the technical foundation; your configuration determines whether you're actually meeting your obligations.

GDPR: Retention, Deletion, and a Hidden Data Loss Vector

GDPR compliance in HubSpot touches several of the mechanisms already covered in this guide. It also introduces a scenario worth treating as its own item on the “ways data gets lost” list from our companion piece, because it's caused not by a mistake, but by a correctly configured privacy feature.

The right to be forgotten, in practice. When a contact requests deletion of their personal data, HubSpot supports what's now called “permanent deletion” (previously referred to as “GDPR deletion”; the same feature with updated terminology). This is a distinct action from a standard delete: at the point of deleting a record, HubSpot presents the choice between “delete with the ability to restore within 90 days” (Recycle Bin) and “permanently delete this contact and all its associated content to follow privacy laws and regulations.” The latter is immediate, removes email tracking history, call records, form submissions, and other engagement data, and is not recoverable through the Recycle Bin at all.

Permanent deletion also adds the contact’s email to a blocklist, preventing re-addition through HubSpot's UI or standard imports. Notably, a permanently deleted contact’s email can re-enter the system if that person submits a website form, emails a connected team inbox, or is added via API. The personal data itself doesn't return (it’s recreated as a new record), but the blocklist isn’t quite the absolute backstop it might appear to be operationally.

Custom retention rules, and the automatic deletion setting that deserves its own warning label. Beyond responding to individual deletion requests, HubSpot provides a setting (framed explicitly around GDPR’s data minimization and storage limitation principles) to automatically delete data for inactive contacts after a configurable period of inactivity. Once a contact meets the inactivity threshold, it’s deleted (with the standard 90-day Recycle Bin window before permanent removal).

This is worth pausing on, because it's a genuinely distinct addition to the “5 Ways” framework: it’s not a mistake, not an attack, not a departing employee. It’s a privacy-positive feature, configured deliberately, often by someone in a compliance or legal role rather than CRM operations, working exactly as designed. And it can still result in the loss of contacts that are dormant but valuable: a seasonal customer, a long-cycle enterprise prospect who went quiet for a year, a partner contact who doesn’t generate activity but matters when they do reach out.

HubSpot’s own documentation is candid about where responsibility sits here: while the feature is provided, your legal team is described as the best resource for compliance advice on your specific situation. That’s the Shared Responsibility Model again, in a particularly sharp form. The feature exists to help you comply with a regulation, but how it's configured (including what counts as “inactive” and whether that definition matches your actual business reality) is entirely a judgment call HubSpot has handed to you.

The practical takeaway: if your organization has this setting enabled, or is considering enabling it, the inactivity threshold deserves the same scrutiny as any other bulk-deletion-adjacent setting in this guide. And critically: if this setting is active, your backup strategy needs to account for it. A point-in-time backup taken before a contact crossed the inactivity threshold is the only way to recover that contact's data after the 90-day Recycle Bin window closes on an automatic deletion. Unlike a manual bulk-delete mistake, an automatic deletion based on an inactivity policy won’t trigger the same “wait, did someone do that on purpose?” scrutiny that might catch a manual error sooner.

SOC 2: Two Different Reports, Easily Conflated

Section 1 introduced this distinction; it’s worth making fully concrete here, because it’s one of the most common points of confusion for organizations going through their own compliance process.

HubSpot’s SOC 2 Type II report is an independent auditor’s verification that HubSpot’s own controls (covering information security policies, access controls, encryption, incident response, vendor management, and change management) are appropriately designed and operating effectively, evaluated over time (not just at a point in time, which is what distinguishes Type II from Type I). This report is available to customers, typically through an account representative or HubSpot’s Trust Center.

Your organization’s SOC 2 report (if your organization undergoes one) is a separate audit of your controls. HubSpot, as a subprocessor, is one input into that audit, not a substitute for it. Your auditor will want to know things HubSpot’s report doesn’t and can’t address: how many Super Admins does your account have, who has access to export customer data, is SSO enforced, what’s your incident response process if your HubSpot account is compromised, is your backup strategy documented and tested.

In practice, this means: HubSpot’s SOC 2 report is something you reference in your own compliance documentation (as evidence about a subprocessor), but everything covered in Sections 2 through 4 of this guide (access control, visibility, backup) is what your own auditor will actually be assessing when the subject is your HubSpot account specifically. An organization that says “we're covered, HubSpot is SOC 2 certified” without being able to speak to its own configuration is likely to find that this doesn’t hold up under audit scrutiny.

HIPAA: The Conditional Picture, Made Actionable

Section 1 laid out the precise mechanics: Sensitive Data properties (Enterprise-only), the opt-in Business Associate Agreement (requiring Sensitive Data activation, Health/Medical category selection, and self-identification as a Covered Entity or Business Associate), and the scoping of coverage to specific “Covered Services.”

Here’s the actionable version, for an organization that has, or is considering, PHI in HubSpot:

• If you haven’t explicitly gone through the Sensitive Data setup and self-identification process, assume no BAA is in place, regardless of your subscription tier. This isn't a default that activates itself; it requires deliberate configuration.

• If you have gone through this process, the BAA covers specific “Covered Services,” not your entire HubSpot account uniformly. Features outside that defined scope (and this notably includes tools where Sensitive Data properties are explicitly unavailable, such as personalization tokens, sandboxes, chatbots, and playbooks) aren’t covered, even on an account where the BAA is otherwise active.
• Backups and exports deserve specific scrutiny. Nothing in HubSpot's Sensitive Data Terms suggests that the native Backup & Restore tool’s CSV exports, or a third-party backup integration, are themselves “Covered Services” under the BAA. If PHI exists in Sensitive Data properties within an account where the BAA is active, an organization needs to separately determine: does our backup process touch this data, and if so, is that process (including wherever the backup is stored) also covered by an appropriate agreement? A BAA covering HubSpot doesn't automatically extend to a third-party backup vendor; that vendor would need its own BAA if PHI flows into its systems.

The throughline: HIPAA compliance in HubSpot isn't a single switch. It’s a chain of decisions: Enterprise tier, Sensitive Data activation, category selection, self-identification, scope awareness, and (if backup is in scope) a separate compliance conversation with whatever sits outside HubSpot. Each link in that chain is the customer’s responsibility to establish and verify.

Data Residency: What “Regional Hosting” Actually Means

HubSpot hosts account infrastructure in regional data centers across the US, EU, Canada, and Australia, and paid accounts can migrate to a preferred region. This connects back to a detail from our backup guide: when HubSpot’s own infrastructure-level backups are used to restore the platform after a disaster, those backups are localized. Restoration happens within the same region, so data doesn’t cross borders during that process.

The compliance-relevant question this raises, and one worth asking explicitly of any third-party backup solution: where does your backup data live, geographically? If your HubSpot account is hosted in the EU for data residency reasons, but your backup solution stores copies in a different region by default, you may have re-introduced the exact cross-border data flow your HubSpot region selection was meant to avoid. This happens through the back door of your backup, rather than through HubSpot itself. This is precisely why “flexible storage” (the ability to choose where backup data is stored, including bring-your-own-storage options) is part of the eleven-point framework in our backup guide. It’s not just a technical preference; it’s a compliance lever.

The preceding five sections cover a lot of ground: access control, visibility, backup, and compliance, each with their own tier dependencies, native tool limitations, and configuration decisions. This section is the synthesis: not new information, but a practical checklist for pulling everything above into an actual program, organized the way an admin or IT/security lead could actually work through it.

This isn’t a one-time project. Several items below are explicitly periodic (quarterly or annual reviews) because configurations drift, people join and leave, and features (like the Breeze AI permission layer discussed in Section 2) get introduced that didn’t exist when the original setup was done.

Access Control

• Count your Super Admins (Settings > Users & Teams). If the number isn’t small and deliberate, it’s your highest-leverage fix.
• Review whether permission sets and Teams reflect your actual organizational structure, or whether they were set up once, early, and never revisited.
• Confirm View-Only seats are being used for stakeholders who need visibility but not edit access.
• If on Enterprise: review Breeze AI object-level permissions specifically. This is a 2026-era permission layer that predates most existing governance reviews.
• Confirm SSO is enforced, with documented exemptions only for continuity planning, and confirm that HubSpot deprovisioning is actually tied to your identity provider's deprovisioning, not a separate manual step.

Visibility

• Check your Security Health Score and act on what it surfaces.

• Enable audit log notifications for multiple exports and removed admin permissions (a few minutes, any tier).
• Establish a periodic (monthly or quarterly) review of Security Activity History, not just the 30-day default view.
• If on Enterprise: periodically review property value change logs and workflow modification logs, especially following any significant automation changes.
• Periodically review HubSpot employee access history, particularly if your account handles Sensitive Data.

Backup & Recovery

• Confirm whether your current backup approach (native tools, manual exports, or a third-party solution) meets the eleven-point framework in our backup guide, with particular attention to point-in-time restore and storage independent of HubSpot’s environment.
• If relying on native tools: understand precisely which are available on your subscription tier, and what their time windows are (14-day export expiration, 90-day Recycle Bin, 14-day “Seamlessly Restore” window on Enterprise).
• Take a backup immediately before any significant bulk operation (imports, bulk edits, major workflow changes) as described in our guide on The Hidden Risk in Every HubSpot Import.
• Run an actual restore test in a sandbox environment. A backup that’s never been restored is unverified.

Compliance 

• Document which compliance frameworks apply to your organization (GDPR, SOC 2, HIPAA, others), and for each, identify what HubSpot’s certifications/agreements cover versus what your own configuration must demonstrate.
• If the automatic deletion setting for inactive contacts is enabled, review the inactivity threshold against actual business reality, and confirm your backup strategy provides a recovery path for data this setting removes.
• If PHI is or might be involved: confirm Enterprise tier, Sensitive Data activation, Health/Medical category selection, and BAA self-identification have all been explicitly completed, and separately confirm whether your backup process is covered by an appropriate agreement.
• If data residency matters: confirm where backup data is stored geographically, not just where HubSpot hosts your account.

Incident Readiness

• Confirm that whoever would respond to a data incident (accidental or malicious) knows where to look first (audit logs, Property History, backup restore points) and has practiced doing so.

• Revisit this checklist after any significant organizational change: a new HubSpot tier, a reorganization, a wave of new hires or departures, or the introduction of new HubSpot features. AI capabilities have moved quickly enough that “we reviewed this a year ago” may no longer be current.

This guide has covered the full scope of what “HubSpot data protection” means: access control as the first line of defence, visibility as the mechanism for catching problems early, backup and recovery as the layer that makes incidents survivable, and compliance frameworks as the lens that ties configuration decisions to actual regulatory obligations.

Each of the scenarios that motivated this guide (and the companion pieces below) maps onto more than one of these areas at once. That's the central point: data protection isn't a single tool or a single setting. It’s the combination of how your account is configured, what you'd notice and when, what you could restore and from where, and what you’ve actually verified rather than assumed.

For deeper treatment of specific areas:

• How to Back Up HubSpot CRM: the complete native-tool breakdown and the eleven-point framework for evaluating backup solutions
• 5 Ways HubSpot Data Gets Lost: the specific failure patterns this guide's access control, visibility, and backup sections are designed to address
• What Happens to Your HubSpot Data If You Cancel Your Subscription?: what the Shared Responsibility Model and inactivity policies mean at the end of a HubSpot relationship
• The Hidden Risk in Every HubSpot Import: a detailed look at one of the most common ways the scenarios in this guide actually begin
• Best HubSpot Backup Solutions Compared (Coming Soon): how leading third-party tools measure up against that framework