The Shared Responsibility Model in HubSpot means the platform provider secures and runs the service, while you control and protect your tenant‑level data inside it. HubSpot is responsible for the security and availability of the application and its underlying infrastructure; you are responsible for who can do what in your portal, how data is changed or deleted, which integrations you authorise, and how you recover from mistakes or misconduct. This distinction is not a technical nicety; it is the foundation of modern data governance, because it clarifies where your accountability begins and what controls you must operate to protect the business.
HubSpot is responsible for maintaining a secure, resilient, and available platform. That remit includes physical and environmental controls at the data centre level, network‑level protections such as firewalls and intrusion detection, security patching and hardening of the application itself, and service continuity measures that keep the platform running when hardware fails or power is interrupted. The company’s commitments and practices are described in its Trust Center, which outlines the controls it operates to secure the platform you use (HubSpot Trust: https://www.hubspot.com/trust).
Once inside your tenant, responsibility shifts to your organisation. You decide who receives administrator rights, what each role can view, edit, export or delete, and which users can bulk‑change or bulk‑remove data (HubSpot permissions: https://knowledge.hubspot.com/account/understand-user-permissions). You are accountable for preventing and detecting human error, such as an accidental deletion or a clumsy CSV import that overwrites key properties, and for mitigating insider risk if a disgruntled user abuses legitimate access. You also own the risk introduced by third‑party apps: an authorised integration acts with the scopes or tokens you grant, and any corruption or mass update caused by a faulty app remains your responsibility to recover (HubSpot OAuth scopes: https://developers.hubspot.com/docs/api/oauth/scopes; private apps: https://developers.hubspot.com/docs/api/private-apps).
They are your accountability because they arise from your tenant‑level choices rather than from weaknesses in the provider’s platform. Only you can set and enforce least‑privilege roles, limit Super Admins to the absolute minimum, and revoke access immediately on departure (HubSpot Super Admin: https://knowledge.hubspot.com/account/super-admin). Only you can train staff on safe imports and high‑risk operations and monitor for anomalous activity through the account activity history available to your tier (https://knowledge.hubspot.com/account/view-your-account-activity-history). Only you can vet marketplace apps, restrict their scopes, test changes in a sandbox and monitor for deletion or update surges after authorisation. In each case, the provider gives you the tools, but you must operate them.
HubSpot’s recycle bin and native restore options are helpful features of the platform, but their retention windows and recoverability vary by object and subscription. Many incidents—especially silent corruption from an integration or cumulative insider changes—are discovered after those limits have expired. The recycle bin is therefore not an insurance policy for your responsibilities; it is a convenience within the platform. An independent, third‑party backup that stores tenant‑level snapshots outside HubSpot is the only reliable way to roll back beyond native limits and without dependence on the person who caused the harm (restore overview: https://knowledge.hubspot.com/crm-setup/restore-records-deleted-from-your-hubspot-account).
A comprehensive backup should preserve the state of your records and the operational context that makes them usable. That means standard objects such as contacts, companies, deals, tickets and products with their properties; custom objects that express your unique data model via the CRM v3 custom object framework; files and attachments with their links to originating records; and the metadata that turns data into a working system, including associations between objects, object properties (types, labels, options and validation) and pipelines and stages for sales and service processes (Custom Objects API: https://developers.hubspot.com/docs/api/crm/crm-custom-objects; Associations API: https://developers.hubspot.com/docs/api/crm/associations; Properties API: https://developers.hubspot.com/docs/api/crm/properties; Pipelines API: https://developers.hubspot.com/docs/api/crm/pipelines; Files API: https://developers.hubspot.com/docs/api/files/files). Where exportable, workflow definitions should also be captured and versioned so automation can be re‑enabled or rebuilt with minimal downtime.
You should define a Recovery Point Objective that states the maximum tolerable data loss per class of data and a Recovery Time Objective that states the maximum acceptable downtime for each function. Many organisations start with an RPO of twenty‑four hours or less for core CRM objects and an RTO measured in hours for sales and service. You should then prove those targets by running quarterly restore drills into a sandbox or isolated tenant and verifying record counts, property schemas, association integrity and attachment accessibility against a written checklist. Evidence such as snapshot IDs, restore job IDs, timestamps, integrity checks and sign‑offs should be retained immutably to show that your ability to restore is not just asserted but demonstrated.
You can evidence control through a small set of measurable targets. For privileged access, keep Super Admins to one or two in total, complete a quarterly privileged‑access review with one hundred per cent coverage, and remediate role drift within five working days. For offboarding, aim to revoke HubSpot access within fifteen minutes of HR notification and rotate any affected integration tokens within twenty‑four hours. For recovery, declare an RPO and RTO per data class and demonstrate attainment through quarterly sandbox restores with documented results. These metrics align with good practice in security management frameworks and make your programme tangible (ISO/IEC 27001 overview: https://www.iso.org/isoiec-27001-information-security.html).
You should begin with a concise audit that reviews access, monitoring, integrations, backups and drills. For access, confirm least‑privilege roles are in place and Super Admins are minimised and reviewed. For monitoring, ensure alerts are configured for risky tenant‑level events such as deletion spikes, unusual exports and bulk property changes. For integrations, validate that OAuth scopes and private app tokens are set to minimum viable privilege and that changes are tested in a sandbox. For backups, confirm you have independent, point‑in‑time snapshots with granular restore and immutable logs. For drills, check that a sandbox restore was successfully completed in the past quarter with evidence retained. Address the highest‑risk gaps first: over‑privileged roles, missing monitoring and the absence of an independent backup.
You should set least‑privilege roles, reduce Super Admins to the bare minimum, and implement an offboarding runbook that revokes access within minutes. You should review authorised apps, narrow their scopes and put a pre‑production gate around any integration that can write or delete at scale. You should implement an independent, third‑party backup that captures records, properties, associations and files at defined points in time and schedule a quarterly restore drill with success criteria. Together these steps meet your side of the shared model and give you a tested safety net for human error, insider actions and app failures.
HubSpot secures the platform and provides native restore features within defined limits, but tenant‑level backup and restore of your data and configuration is your responsibility. An independent, point‑in‑time backup is the only reliable way to roll back beyond native limits and without dependence on the person who caused the harm (HubSpot Trust: https://www.hubspot.com/trust; restore overview: https://knowledge.hubspot.com/crm-setup/restore-records-deleted-from-your-hubspot-account).
You should not rely on it as your only control. Retention windows and recoverability vary by object and subscription, and many incidents are discovered after those windows. Independent backups ensure rollback beyond native limits and let you restore surgically rather than all‑or‑nothing.
You do. You choose the app, authorise the OAuth scopes or private app token, and must monitor and recover if it misbehaves. Apply minimum viable scopes, test in a sandbox and maintain an independent backup so you can recover quickly (OAuth scopes: https://developers.hubspot.com/docs/api/oauth/scopes; private apps: https://developers.hubspot.com/docs/api/private-apps).
At a minimum, it should include standard and custom objects with their properties, associations between objects, files and attachments with their links, and configuration metadata such as pipelines and object properties. Where exportable, workflow definitions should be captured or documented so automation can be re‑enabled or rebuilt.
Tie them to business impact. For many organisations, an RPO of twenty‑four hours or less for core CRM objects and an RTO measured in hours for sales and service is a pragmatic baseline. Prove your targets through quarterly sandbox restores and retain evidence such as snapshot IDs, restore job IDs, integrity checks and sign‑offs.
Keep Super Admins to the absolute minimum—often one or two—and review the role quarterly to confirm necessity and prevent drift. Reserve the role for operationally critical tasks with clear separation of duties (Super Admin overview: https://knowledge.hubspot.com/account/super-admin).
Yes. The account activity history, where available, can show logins and critical actions during offboarding or incident investigation. Incorporate a log review step into your procedures so you can reconstruct who did what and when (https://knowledge.hubspot.com/account/view-your-account-activity-history).
Start with a short assessment. Inventory your data model, role design, authorised apps and current restore options; implement an independent, point‑in‑time backup; and schedule your first sandbox restore drill with success criteria. In parallel, reduce Super Admins and formalise your offboarding runbook with a fifteen‑minute access revocation target.
HubSpot Trust Center: https://www.hubspot.com/trust
HubSpot user permissions: https://knowledge.hubspot.com/account/understand-user-permissions
HubSpot Super Admin: https://knowledge.hubspot.com/account/super-admin
HubSpot account activity history: https://knowledge.hubspot.com/account/view-your-account-activity-history
Restore deleted records overview: https://knowledge.hubspot.com/crm-setup/restore-records-deleted-from-your-hubspot-account
HubSpot OAuth scopes: https://developers.hubspot.com/docs/api/oauth/scopes
HubSpot private apps: https://developers.hubspot.com/docs/api/private-apps
ISO/IEC 27001 overview: https://www.iso.org/isoiec-27001-information-security.html
NCSC cloud security collection: https://www.ncsc.gov.uk/collection/cloud-security
This article provides operational guidance to help you meet your responsibilities under the Shared Responsibility Model in HubSpot. It does not constitute legal advice. Where personal data is involved you should consult legal and compliance advisers about breach assessment and notification obligations under applicable law.