HubSpot GDPR Compliance: The Consent Gaps EU Websites Must Fix
Ask "is HubSpot GDPR compliant?" and you'll get a reassuring "yes, with the right settings." That's true for one half of the picture — the CRM and email side, where HubSpot ships genuinely good tooling. But there's a second half most guides skip, and it's the one that actually draws regulator attention: the moment a visitor lands on your site, HubSpot's tracking code sets cookies before anyone has consented — and HubSpot's own banner doesn't stop it. This guide separates the two problems cleanly, then walks through the specific consent gaps EU and UK sites have to close in 2026.
Key takeaways
- "HubSpot GDPR compliance" is really two separate problems. One is HubSpot as a data processor (contacts, emails, the DPA) — well tooled. The other is HubSpot's tracking on your website — where the consent gaps live.
- HubSpot's tracking code sets cookies before consent by default. The standard install loads on every visit and drops multi-session cookies immediately — which GDPR and the UK's PECR both prohibit without prior opt-in.
- The native HubSpot banner is a notice, not a control. It doesn't technically block the tracking script before consent, and it only appears on HubSpot-hosted pages — not your main website.
- Analytics needs consent in the EU and UK. The ICO's April 2026 guidance confirms non-essential analytics require prior consent; the narrow new PECR exemption doesn't cover HubSpot's cross-session, CRM-linked tracking.
- The fix is prior blocking. A real consent layer that blocks HubSpot's script until the visitor opts in — on every page, EU and UK visitors alike — closes the gap the native banner leaves open.
The two problems hiding in one question
The single biggest reason "is HubSpot GDPR compliant?" produces so much confusion is that the question smuggles two very different problems under one name. Answer them together and you get mush. Separate them and everything clarifies.
HubSpot as a data processor
The CRM and marketing back end: contact records, email sends, lawful basis, subscription types, the Data Processing Agreement.
HubSpot gives you real, usable tools here. Your job is to switch them on and configure them.
HubSpot's tracking on your site
The tracking code, cookies, forms, and chat widget that run in the visitor's browser the moment a page loads.
This is where the consent gaps live — and where the native tools fall short. It's the focus of this guide.
Most articles answer Lane A ("yes, sign the DPA, enable GDPR tools") and quietly imply that settles the whole question. It doesn't. You can have a perfectly configured CRM — DPA signed, lawful basis set, subscription types tidy — and still be dropping tracking cookies on every EU and UK visitor before they've consented to anything. Lane A is about the data you hold. Lane B is about what fires in the browser. They're governed by overlapping but distinct rules, and closing one does nothing for the other.
We'll cover both — but we're going to spend most of our time in Lane B, because that's the gap that gets missed, and it's the one a regulator or a privacy-conscious visitor sees first.
The core gap: cookies before consent
Here's the technical fact everything else hangs on. When you install HubSpot's tracking code the standard way — the snippet in your site's <head> — that script loads on every page visit and sets its cookies immediately. Not after a click. Not after consent. On load.
Those cookies aren't trivial. They're multi-session tracking cookies that build the visitor timeline you see inside HubSpot — pageviews, clicks, scroll depth, session duration — and they underpin every lead-scoring rule and workflow you've built. The hubspotutk cookie in particular is the thread that stitches an anonymous visitor to a named contact record the moment they submit a form. That's powerful for marketing. It's also exactly the kind of cross-session, identity-linking tracking that European regulators treat as requiring consent before it happens.
Under both the EU's GDPR/ePrivacy regime and the UK's PECR, consent for non-essential cookies must be prior — given before the cookie is placed. A script that fires on page load has, by definition, already acted before the visitor chose.
— The rule HubSpot's default install collides withSo the default HubSpot setup on a European-facing site isn't a grey area you can argue about — it's a straightforward mismatch with the rule. The tracker acts first; the consent question, if it's asked at all, comes second. And that ordering is the whole ballgame.
Why HubSpot's native banner isn't enough
HubSpot does ship a built-in consent banner — you'll find it under Settings > Privacy & Consent. It's genuinely useful for what it is, and for a very small, low-risk operation it might even be adequate. But if you're serious about EU or UK compliance, it has four limitations that matter, and they're not obvious until you look closely.
This is the big one. The native banner is a notice layer, not a control layer — it displays a message and records a choice, but it does not technically prevent the HubSpot tracking code from firing and setting cookies before the visitor decides. Since prior blocking is the entire point of the exercise under GDPR and PECR, a banner that doesn't block doesn't solve the core problem.
The native banner is designed for pages hosted in HubSpot's CMS. If your main website runs on WordPress, Shopify, Webflow, or anything else — with the HubSpot tracking code embedded in it — the native banner doesn't cover those pages. Which is to say: for many businesses, it doesn't cover the site that actually matters.
European regulators expect visitors to be able to consent by category — strictly necessary, functional, analytics, marketing — as separate choices. The native banner doesn't cleanly separate these into distinct toggles, so it struggles to deliver the "specific" and "granular" consent that valid GDPR consent requires.
If you run programmatic advertising, you need a Google-certified consent framework that emits a valid transparency-and-consent signal. The native HubSpot banner doesn't participate in the IAB TCF or GPP frameworks, so it can't pass the consent state along to the ad-tech chain the way a certified CMP does.
None of this is HubSpot hiding the ball — their own documentation is upfront that "your legal team is the best resource" for compliance, and they position the banner as a helper, not a guarantee. The mistake is on the user side: treating a notice tool as if it were a control tool. The people who get caught out are the ones who saw "HubSpot has a cookie banner," switched it on, and assumed the consent question was handled.
See exactly what HubSpot fires on your site before consent
Run a free scan and see which HubSpot cookies — and every other tracker — load before a visitor opts in. It's the same check a regulator's assessment (or a privacy complaint) would start with. About 10 seconds, no account.
Scan your site free →Which HubSpot cookies need consent
To close the gap you need to know what you're actually gating. HubSpot's tracking surface sets several cookies, and the important distinction is which are strictly necessary (exempt from consent) versus which are analytics or functional (consent required). The main ones to know:
| Cookie | Purpose | Typical life | Consent? |
|---|---|---|---|
__hstc | Main analytics tracking — visitor timeline, sessions | ~6 months | Required |
hubspotutk | Identifies the visitor; links to a CRM contact on form submit | ~6 months | Required |
__hssc | Tracks the current session | ~30 min | Required |
__hssrc | Detects whether the visitor restarted the browser | Session | Functional |
messagesUtk | HubSpot chat widget — identifies chat visitors | ~1 year | Required |
Two practical notes. First, the chat widget is a frequent blind spot — if you run HubSpot chat, the messagesUtk cookie (which lasts around a year) has to appear in your cookie policy and be included in your consent request; it's easy to forget because "chat" doesn't feel like "tracking." Second, because hubspotutk links browsing behaviour to an identifiable person once a form is submitted, this isn't anonymous analytics in the regulator's eyes — it's personal-data processing, which raises the bar rather than lowering it.
What GDPR and PECR actually require in 2026
Let's ground the "why" in the current rules, because they've moved recently and the detail matters for HubSpot specifically.
The EU position
Under the GDPR and the ePrivacy rules that member states implement nationally, placing non-essential cookies requires prior, opt-in consent that is freely given, specific, informed, and unambiguous. No pre-ticked boxes, no "by continuing to browse you agree," no cookie walls that withhold the site until you accept. Accept and Reject must be offered with equal prominence. HubSpot's analytics cookies are non-essential under this test, so they require consent before they're set.
The UK position
The UK retained these requirements through PECR (the Privacy and Electronic Communications Regulations) and UK GDPR, both enforced by the ICO. PECR Regulation 6 is explicit: a person must be given clear information and must consent before a non-essential cookie is placed. The ICO's finalised Storage and Access Technologies guidance, issued in April 2026, confirms that non-essential analytics require prior consent. There is a narrow new exemption in force from February 2026 — but it covers only first-party, sole-purpose statistical analytics with clear information and a free opt-out. HubSpot's tracking, which is cross-session, links to a CRM identity, and transmits data to a US processor, does not fit inside that narrow carve-out.
For a fuller breakdown of the UK side specifically — including the February 2026 exemptions and what they do and don't cover — see our guide to UK cookie law and PECR in 2026.
The processor side: DPA, lawful basis, Article 30
Lane B — the website tracking gap — is where most of the risk hides, but Lane A still has to be handled, and it's genuinely more straightforward because HubSpot gives you the tools. Here's the short, accurate version of what the processor relationship requires.
- Sign the DPA. HubSpot acts as a data processor for the personal data in your CRM, which means a signed Data Processing Agreement is mandatory. It's available in your account settings under the legal/account-defaults section — accepting it activates it for your account and connected products. This is a five-minute job that a surprising number of organisations skip.
- Enable GDPR tools — deliberately. HubSpot's GDPR functionality isn't on by default; you enable it in settings. One important caveat: enabling it is a one-way change that alters how contact records work and can't be reversed, so read what it does before you flip it, rather than after.
- Set lawful basis and use subscription types. HubSpot supports "lawful basis to communicate" tracking per contact and granular subscription types for different communication categories. Use them — they're how you demonstrate the basis for each contact and honour granular email consent rather than treating one opt-in as blanket permission.
- Configure forms properly. Turn on the GDPR options per form so that consent to process and consent to communicate are explicit, separate checkboxes — never pre-ticked — with a link to your privacy policy.
- Put HubSpot in your Article 30 record. GDPR requires a record of processing activities; HubSpot belongs in it as a processor, with the categories of data, the US transfer, and the safeguards (Standard Contractual Clauses and the EU-US Data Privacy Framework, plus the signed DPA) documented.
- Mind data location and retention. EU data hosting is only available on Enterprise plans; otherwise processing involves a US transfer under the frameworks above. And set retention sensibly — the ICO suggests not keeping tracking data beyond 13 months.
How to close the gaps — a checklist
Pulling both lanes together, here's the concrete sequence. The first item is the one that closes the gap this whole article is about; the rest make the picture complete.
messagesUtk cookie in your cookie policy and consent request, and gate it like any other non-essential cookie.Where ConsentPixel fits — and where it doesn't
Worth being precise, because the two lanes need two different kinds of help. ConsentPixel handles Lane B: it's a consent layer that blocks HubSpot's tracking code — and every other third-party script — from firing until the visitor consents, on any site regardless of what it's built on, with an equal-prominence banner and a timestamped consent log for every choice. Because it's region-aware, an EU visitor gets a GDPR-appropriate experience and a UK visitor a PECR-appropriate one, on the same site. That directly closes the "script fires before consent" gap and the "native banner only works on HubSpot pages" gap in one move.
What ConsentPixel does not do is Lane A. It won't sign your HubSpot DPA, build your Article 30 record, or configure your CRM's lawful basis for you — those are your processor-side responsibilities, and HubSpot's own tools are where you handle them. Think of it as a clean division of labour: HubSpot's settings and your documentation cover the data you hold; a consent layer covers what fires in the visitor's browser. You need both, and they don't overlap.
Five HubSpot GDPR mistakes that keep recurring
Across audits of HubSpot-running sites, the same handful of errors come up again and again. None of them require deep legal knowledge to avoid — they're mostly a matter of knowing they exist. If you check nothing else, check these.
- Mistaking the native banner for a CMP. The most common error, and the one this article exists to correct: switching on HubSpot's banner and assuming the consent question is handled, when the banner doesn't block the script and doesn't cover non-HubSpot pages. It complements a consent platform; it doesn't replace one.
- Never signing the DPA. The Data Processing Agreement is a required contract with your processor, it takes minutes, and it's genuinely easy to overlook because nothing in the product forces you to do it. An unsigned DPA is a clean, documentable compliance failure that a regulator can spot instantly.
- Forgetting the chat widget. Teams gate their analytics cookies and then leave the HubSpot chat widget's year-long
messagesUtkcookie firing unlisted and unconsented, because "chat" doesn't feel like tracking. It is, and it needs the same treatment. - Pre-ticked or bundled form consent. A single checkbox that bundles "process my data" and "send me marketing," or a box that's ticked by default, fails the specific-and-freely-given test. Processing consent and communication consent are separate, explicit, unticked choices.
- Treating SOC 2 or "HubSpot is compliant" marketing as your compliance. HubSpot's own certifications describe HubSpot's security posture, not your configuration. Your compliance is the sum of the choices you make in the settings and on your website — it isn't inherited from the vendor.
Frequently asked questions
Is HubSpot GDPR compliant?
HubSpot provides the tools to support GDPR compliance, but it isn't "compliant" on your behalf — compliance depends on how you configure and operate it. On the CRM side, you must sign HubSpot's Data Processing Agreement, enable its GDPR tools, set lawful basis, and configure forms with explicit consent. On the website side, HubSpot's tracking code sets cookies before consent by default and its native banner doesn't block that, so you need a consent layer that gates the tracking script until a visitor opts in. Handle both and you're in a defensible position; handle only the CRM side and you've left the website gap open.
Does HubSpot set cookies without consent?
By default, yes. The standard HubSpot tracking code installed in your site's head loads on every visit and sets its analytics cookies immediately, before any consent is captured. Under the EU's GDPR/ePrivacy rules and the UK's PECR, non-essential cookies require prior consent — meaning consent before the cookie is placed. To comply, the HubSpot script needs to be blocked by a consent layer until the visitor opts in; simply showing a banner while the cookies have already been set does not meet the requirement.
Is HubSpot's built-in cookie banner enough for GDPR?
Usually not for EU or UK sites. HubSpot's native banner is a notice layer rather than a control layer — it doesn't technically block the tracking script before consent — and it only operates on HubSpot-hosted pages, not a main website built on another platform. It also lacks granular per-category consent toggles and IAB TCF/GPP support. For a small, low-risk operation it may suffice, but most European-facing businesses need a dedicated consent management platform that performs prior blocking across their whole site.
Do I need to sign a DPA with HubSpot?
Yes. HubSpot acts as a data processor for the personal data you hold in it, so a signed Data Processing Agreement is a mandatory part of GDPR compliance. It's available in your HubSpot account settings under the legal/account-defaults section, and accepting it activates it for your account and connected products. You should also record HubSpot as a processor in your Article 30 record of processing activities, documenting the US data transfer and the safeguards that cover it.
Does the February 2026 UK analytics exemption cover HubSpot?
No. The PECR exemption that came into force in February 2026 is narrow — it covers only first-party, sole-purpose statistical analytics, with clear information and a free opt-out. HubSpot's tracking is cross-session, links browsing to an identifiable CRM contact once a form is submitted, and transmits data to a US processor, so it falls outside that carve-out. The ICO's April 2026 guidance confirms that non-essential analytics of this kind still require prior consent under PECR.
Will blocking HubSpot until consent break my tracking and lead scoring?
It changes what you collect from visitors who decline, which is the intended effect — you shouldn't be tracking people who haven't consented. For the large share of visitors who do consent, HubSpot works exactly as before, and your timelines, lead scoring, and workflows populate normally. The trade-off is a modest reduction in data from non-consenting visitors against removing a clear compliance gap; for European-facing businesses, that's generally a straightforward decision.
The bottom line
"Is HubSpot GDPR compliant?" is the wrong question because it hides two different problems. HubSpot the data processor is well tooled — sign the DPA, enable the GDPR settings, configure your forms and lawful basis, and that side is in good shape. HubSpot the website tracker is where the gap lives: its code sets cookies before consent by default, and its native banner shows a notice without blocking the script.
Both the EU's GDPR and the UK's PECR require the opposite — prior consent, before the cookie is set — and with the UK fine ceiling now at £17.5 million and regulators actively pressing on cookie banners, the website gap is the part worth closing first.
The fix is not complicated: put a real consent layer in front of HubSpot's tracking code so nothing fires until the visitor opts in, across your whole site and for EU and UK visitors alike. The quickest way to know how big your gap is right now is simply to look at what HubSpot is firing before consent today.
See what HubSpot fires before consent
Scan your site to see exactly which HubSpot cookies — and every other tracker — load before a visitor opts in. Free, about 10 seconds, no account required.
Scan your site free →About this article: This piece is for informational purposes only and is not legal advice. It describes, in general terms, how HubSpot's tracking and processor functions intersect with the EU GDPR/ePrivacy regime and the UK's PECR and UK GDPR as understood in August 2026; HubSpot's product features and regulatory guidance change, so verify current settings and requirements directly and consult qualified counsel about your specific circumstances. ConsentPixel — Privacy · Verified is a consent-infrastructure provider that blocks third-party and tracking scripts from firing before consent and logs consent decisions; it does not sign your Data Processing Agreements, build your records of processing, or configure your CRM, and it does not by itself make any website "GDPR compliant."