HubSpot Integration Security and UK GDPR: A Practical Guide

An integration is not just a technical convenience. Legally, it is a data processing operation: personal data about your contacts and customers flowing between systems, often through infrastructure you did not build and companies you have never audited. Under UK GDPR you remain responsible for that flow. This guide covers the security decisions that actually matter when connecting HubSpot to your other systems, in plain English. It is practical guidance, not legal advice.

Authentication: scopes are the whole game

Most integrations authenticate with OAuth or with API keys, and the difference matters. OAuth grants scoped access: the integration can be limited to exactly the objects it needs, the grant is visible and revocable, and nothing shared resembles a password. Static API keys are blunter: they frequently grant broad access, they end up pasted into no-code tools and spreadsheets, and they keep working long after everyone has forgotten they exist.

Whatever the mechanism, the rule is least privilege: an integration that syncs invoices does not need permission to read marketing contacts or delete records. Ask of every connection you run today: what exactly can this credential do, and who can see the credential itself? Secrets belong in a proper secret store with rotation, not in a shared document.

Where does the data actually go?

This is the question middleware quietly complicates. When system A talks directly to system B over TLS, your data has two homes and an encrypted journey between them. When a no-code middleware platform sits in the middle, your customer data routinely passes through, and is often stored by, a third company, on infrastructure in a jurisdiction you have not checked, under a retention policy you have not read.

That does not make middleware illegal; it makes it a sub-processor, which brings obligations: a data processing agreement needs to be in place, your privacy notices and records of processing should reflect it, and if the data leaves the UK you need a lawful transfer mechanism (adequacy, or safeguards such as the UK IDTA or addendum). If nobody in your business can name the middleware vendors in your stack today, that is the audit to run first. One of the quieter advantages of a custom, real-code integration is architectural: data moves directly between your systems, encrypted in transit, with no third-party platform holding a copy, which shortens your processor chain and your risk register at the same time.

Minimise what you move

GDPR's data minimisation principle applies to sync design directly: move the fields the receiving system needs, not everything the API offers. Syncing entire contact records into a finance system because the connector defaulted to "all fields" creates risk with no business benefit. Be especially deliberate about anything sensitive; most finance and operations integrations need names, companies, addresses and transactions, and very little else.

Governance that survives an audit

Know your flows. A one-page data map per integration: what objects, which direction, what triggers, where data rests. This is also, not coincidentally, the scoping document a good integration build starts from.

Keep audit trails. Logs of what synced, when, and what failed. When someone exercises their rights, or something goes wrong, you need to reconstruct what happened to a record.

Control the humans. Credentials tied to named service accounts rather than employees' personal logins, access removed when people leave, and a named owner per integration, which is as much a security control as an operational one; see who should own your integration.

Assess before you build. For high-risk processing a DPIA may be required; for most B2B integrations a lightweight risk review at scoping time is proportionate and cheap.

What we do about all this

SpotDev is Cyber Essentials Plus certified, we work under data processing agreements, and we design integrations GDPR-first: least-privilege scopes, direct system-to-system architecture with no middleware copies, encrypted transport, audit logging and documented data maps as standard. Security questions are also excellent partner-selection questions; we have listed the rest in how to choose a HubSpot integration partner.

Frequently asked questions

Is a HubSpot integration covered by UK GDPR?

Yes. Moving personal data between HubSpot and other systems is processing, and you remain responsible for it, including any middleware vendors in the chain, who act as sub-processors and need data processing agreements.

Is OAuth safer than an API key for integrations?

Generally yes. OAuth grants scoped, revocable, visible access, while static API keys often grant broad access and outlive their purpose. Either way, apply least privilege and store secrets in a proper secret store with rotation.

Does data pass through a third party in a custom integration?

It does not have to. A custom, real-code integration can move data directly between your systems, encrypted in transit, with no middleware platform storing a copy, which shortens your processor chain compared with no-code middleware.

Connecting systems that hold customer data? Start with the complete guide to connecting anything to HubSpot, or talk to us about custom HubSpot integration services built GDPR-first by a Cyber Essentials Plus certified UK team.