A working demonstration tells you that information can move between systems. It does not answer who can access that information, where credentials will live or what happens when the agency relationship ends.
We recommend asking those questions before commissioning the integration. The goal is to obtain a reviewable design and clear responsibilities, with the right specialists involved where the data or obligations require them.
TLDR: Ask for the data flow, permission scope, credential custody, environment separation, logging rules, access-removal process and incident ownership. Request evidence rather than a general assurance that the integration is secure. Treat sensitive data as a separate approval and technical review, not an ordinary field-mapping decision.
Ask what information actually needs to move
Request a data-flow diagram that names the source, destination, intermediary services and purpose of each transfer. Ask for the fields involved and the reason each one is necessary to the business process.
Then ask what will stay out of the integration. A full source payload should not become the default requirement merely because the connection can retrieve it. Have the business owner approve the information needed for the defined use case.
Use the HubSpot portal audit checklist to identify the relevant systems and processes. The integration review should go deeper on the actual data boundary and the proposed access.
Ask for the permissions in plain language
Have the agency explain what each requested permission allows and which operation needs it. Ask whether it permits reading, creating, updating or deleting information, and in which account or environment.
HubSpot documents that an API request can return 403 when its authentication lacks the permissions required for the endpoint. HubSpot's error-handling documentation makes permission scope a concrete part of the design review.
A permission error should lead to a review of the approved operation and scope. It should not automatically lead to granting every available permission. Ask who approves a scope change and how the revised access is recorded and tested.
For human access, keep a separate list of the people and roles who need to configure, review or support the connection. Do not assume that an application's permission design also answers the user-access question.
Ask who controls credentials and removal
Request a written description of where credentials are stored, who can retrieve or use them, and how access is granted and removed. The description should identify the approved secret-management system without including the secret itself.
Ask how the team would rotate a credential, respond to suspected exposure and remove agency access without losing control of the integration. Establish who owns the relevant accounts and who can perform those actions if the original developer is unavailable.
- Ownership evidence. Request a record of the business-controlled accounts and administrative responsibilities.
- Access evidence. Request the approved roles and the process for reviewing them when personnel change.
- Removal evidence. Request a documented offboarding procedure and a way to verify that access has ended.
- Continuity evidence. Request the instructions an authorized replacement maintainer would need to operate the connection.
These are procurement questions. They do not establish that a particular storage product or authentication approach is appropriate for every integration.
Ask what reaches logs and test environments
Request a sample of the proposed log format with synthetic data. Ask which fields are recorded, where logs are stored, who can access them and how long they are retained. Have the appropriate owner approve those choices.
The same review should cover error alerts, support tickets and debugging exports. Information excluded from a primary destination can still appear in a copied payload if the logging design is not reviewed.
Ask how development and testing are separated from production. Request a test-data plan that avoids unnecessary exposure of real customer information. If real data is required, ask for the specific justification, access boundary and approval rather than treating that choice as automatic.
Our overview of HubSpot integrations can support the initial inventory. It is not a security assessment of any listed connector or implementation.
Treat sensitive data as a separate decision
HubSpot's Sensitive Data API documentation describes additional object-specific access scopes, supported API limitations and an Enterprise subscription requirement for Sensitive Data functionality. Read HubSpot's Sensitive Data documentation for the current restrictions.
That capability does not establish that your proposed transfer, storage, logging or use is appropriate. Ask the agency to identify any sensitive categories before implementation and route the design to your qualified security, privacy or legal reviewer as needed.
Do not accept a general claim of compliance as a substitute for reviewing the exact data, jurisdictions, contracts and implementation. This article provides technical procurement questions, not legal advice or a compliance determination.
Turn HubSpot integration security questions into evidence requests
A secure integration proposal should make the security controls reviewable by your responsible stakeholders. Ask for a written response tied to the actual connected apps, environments and business operations in scope. A generic HubSpot security overview does not explain what an agency will store, configure or operate outside the HubSpot platform.
Use the questions below as procurement prompts. They are not a thorough security audit, a certification, or a substitute for your security team's assessment. The answer may be “not applicable,” but it should explain why and identify the person accountable for that decision.
How will user authentication and API access be separated?
Ask which people need interactive user access and which components need API access. Request the appropriate scopes for each proposed app and a reason for every permission. A developer needing access to one integration should not automatically receive unrestricted access to all business and customer data.
Have the provider identify its authentication method and credential custodian. Where private app tokens are proposed, ask who can obtain, rotate and revoke them. Where another method is proposed, request the corresponding procedure. A document that says only “API keys” is too vague to approve; references to legacy API keys should trigger a current authentication review before any access is granted.
Which access controls apply to people?
Ask whether two-factor authentication or multi-factor authentication is required for the relevant human accounts, how it is enforced and which exceptions exist. Check the provider's systems as well as your HubSpot portal. A control applied to one login should not be assumed to protect every connected service or credential.
Request a current access list that separates active users, inactive users, former employees and service identities. Identify who approves access, who reviews it and who removes it. If multiple users need different duties, ask how the design will restrict access to only what each role needs. Record any access risk that remains open.
What protects data in transit and in storage?
Ask for the actual data encryption and transport controls for every connection. Which encryption protocols are used, where is transport layer security terminated, and what happens if a connection cannot be established securely? Ask the provider to distinguish configured controls from features that are merely available.
Map data storage separately: primary databases, queues, temporary files, backups, logs and support attachments. For each location, identify the stored data, who can access it, the retention rule and the removal process. An integration that transfers only a few customer fields may still place sensitive information in an error log unless that path has been considered.
What would incident response look like?
Request an incident response plan for suspected credential exposure, unexpected exports, unauthorized changes and other relevant security incidents. Name the initial contact, decision owner and escalation route. Ask which party can pause the integration and how the team would determine whether customer data was affected.
Ask the provider to walk through a fictional data-breach alert using synthetic details. What evidence would be preserved, which credentials would be examined, and who would decide the communication response? Security monitoring is more useful when the team has agreed what an alert requires someone to do.
How will ongoing monitoring find security gaps?
Request the audit logs, login history or API usage evidence available for the proposed components, together with retention and access limitations. Ask how unusual usage patterns, unexpected permissions or new data destinations would be noticed. Distinguish automated alerts from checks that depend on a person reviewing a report.
Set a review cadence for permissions, inactive integrations, software changes and unresolved vulnerabilities. Do not call the arrangement continuous monitoring unless the provider can show what is monitored continuously. Regular security audits and operational reviews should produce dated findings, owners and closure evidence, not just an assurance that the integration is secure.
Who decides which compliance requirements apply?
Have qualified legal, privacy and security stakeholders determine the applicable data protection regulations, contracts and industry standards. Ask what evidence they need before information may move. Do not infer compliance from a vendor's general marketing statement or from the existence of an enterprise subscription.
If the proposal includes personally identifiable information or regulated data, document the approved purpose and destination before configuration begins. Questions about HIPAA compliance or other specialized requirements belong with the appropriate specialists. This questionnaire does not determine legal obligations or certify a system's security posture.
Test the answers with an offboarding scenario
Hypothetical example: Your agency contact leaves and a different authorized provider must maintain the integration. Can your team identify the business-owned accounts, revoke the former access, locate the source and configuration, and verify that the connection still works?
Ask the provider to walk through that scenario using its proposed handover. Any step that depends on an undocumented personal account or an unavailable person should be resolved before acceptance.
Also walk through a suspected credential exposure. Clarify who receives the report, who can contain the issue, who investigates and who communicates with the business. Keep notification obligations with the qualified reviewers responsible for the relevant agreements and laws.
Frequently asked questions
Does an integration being listed in a marketplace replace security review?
No. Your decision still needs to address the proposed data flow, permissions, credential custody and operating responsibilities. Ask for evidence specific to the design you intend to approve.
What should the agency hand over before access is granted?
We recommend a data-flow description, a permission list with reasons, named access owners, test-data rules and a removal procedure. Have the appropriate security and privacy stakeholders assess the proposal before issuing credentials.
Should production customer data be included in demonstrations?
Use approved synthetic or otherwise authorized test data. Establish what may appear in logs, screenshots and support tickets before a demonstration. Do not assume a sales presentation is an approved destination for customer information.
Make evidence part of the deliverable
We recommend including the approved data flow, permission list, credential-ownership description, log specification, test evidence and offboarding procedure in the integration handover. Define who updates them when the design changes.
If your team needs help reviewing the business and technical scope, explore consulting services and HubSpot operations. Bring the proposed data flow and the unanswered questions, with any specialist review requirements stated explicitly.
Official product documentation checked August 30, 2026. Account eligibility, security design and any legal obligations require separate review before implementation.
