Is GoHighLevel HIPAA Compliant? BAA, Add-On Requirements and Setup Limits

Let me be very clear: GoHighLevel is not HIPAA compliant by default. HighLevel currently offers a paid agency-wide HIPAA add-on with a Business Associate Agreement and account controls, but the agency must purchase it, sign the BAA and enable HIPAA for every required sub-account. The practice and agency still need their own policies, risk analysis, workforce controls and vendor agreements.

The honest answer is that buying the add-on does not make an organization automatically compliant. It gives you one properly configured platform component inside a much wider HIPAA program.

This article provides general implementation information, not legal advice. A covered entity or business associate should have qualified legal and compliance professionals review its obligations and specific setup.

For practical implementation context, review the AI receptionist workflow for dentists, the separate rules around Voice AI outbound-call consent, and the AI appointment-setter handoff. Store sensitive workflow data deliberately by choosing the correct custom field or object.

First, here is what HighLevel currently requires

As of July 18, 2026, HighLevel’s HIPAA compliance guide lists:

• An optional agency-wide HIPAA add-on.
• A signed Business Associate Agreement with HighLevel.
• Automatic agency-level activation after the BAA is signed.
• A separate Advanced Settings toggle for each sub-account that requires HIPAA protection.
• Encryption, audit logging, and MFA-related safeguards described in the package.
• A current price of US$297 per month.
• Permanent activation that cannot be canceled, refunded, removed, downgraded, or disabled after purchase according to the current documentation.

Pricing and policy can change. Read the live Before You Buy details and the actual agreement before purchasing. Do not rely on an old screenshot or this article for a non-reversible billing decision.

Who is the covered entity and who is the business associate?

In a common healthcare agency arrangement:

• The healthcare practice may be the HIPAA covered entity.
• The marketing or implementation agency may be a business associate when it creates, receives, maintains, or transmits protected health information for the practice.
• HighLevel may be the agency’s or practice’s cloud-service business associate for the services covered by its BAA.
• Other vendors can be downstream business associates when they handle PHI.

The exact roles depend on the parties and work performed. The U.S. Department of Health and Human Services says a cloud provider that creates, receives, maintains, or transmits ePHI on behalf of a covered entity or business associate is itself a business associate, even when the data is encrypted and the provider does not hold the decryption key. The parties need an appropriate BAA and must otherwise comply with the HIPAA Rules. See the HHS cloud-computing guidance.

An agency working with a practice normally needs its own BAA with the practice. HighLevel’s BAA with the agency does not replace that agreement.

What the BAA does and does not do

A Business Associate Agreement defines permitted uses and disclosures of PHI, safeguards, reporting, subcontractor obligations, and what happens to PHI at termination, among other terms.

A BAA does not:

• Train the workforce.
• Decide which staff should access each record.
• Make every connected application compliant.
• Prevent a user from pasting PHI into an unsafe tool.
• Configure data retention or incident response for the organization.
• Prove that every workflow follows the minimum-necessary principle.
• Replace the required risk analysis and risk-management process.

HHS provides business associate contract guidance, but the actual agreements and business relationships need professional review.

How to enable the GoHighLevel HIPAA package

The current HighLevel process is agency-led.

Step 1: Open the Compliance area

At Agency level, go to Settings > Compliance. Confirm you are in the correct agency and that the owner or authorized administrator is performing the review.

Step 2: Read the Before You Buy terms

Review:

• Current monthly price.
• Agency-wide scope.
• BAA process.
• Permanent activation and cancellation limitations.
• Which controls become mandatory.
• Payment method and billing owner.

Stop if any term is unclear. This is not a setting to enable for a screenshot test.

Step 3: Purchase the package only after approval

Only an authorized agency owner should confirm the acknowledgement and payment. If you are auditing the setup, stop before the final confirmation.

Step 4: Review and sign the BAA

Complete the signer information accurately and have the authorized party review and sign the agreement. Keep an approved copy with the organization’s vendor and compliance records.

Step 5: Enable HIPAA for each required sub-account

After the agency package and BAA are active, go to the intended sub-account’s Advanced Settings and enable the HIPAA setting according to HighLevel’s current instructions.

HighLevel warns that the location setting cannot be turned off after it is enabled. Confirm the sub-account name, client, and authorization before changing it.

Step 6: Verify the actual security behavior

Do not stop at the toggle. Confirm:

• MFA expectations for every user.
• User roles and minimum required permissions.
• Audit log access and retention available to the organization.
• Data export and deletion procedures.
• Secure user offboarding.
• Approved communication channels.
• Backup, availability, and incident procedures.
• Vendor and integration inventory.

The setup limits that matter most

Connected applications need their own review

A HIPAA-enabled HighLevel location can still send data to:

• Google or Outlook calendars.
• Email providers.
• Phone and SMS providers.
• Meta and Google advertising systems.
• Zapier, Make, or custom webhooks.
• AI services.
• Payment, document, accounting, and analytics tools.

The HighLevel add-on does not automatically extend its BAA or controls to every connected provider. List each system that can receive PHI, determine its role, review its agreement, and disable flows that are not approved.

Ordinary marketing data can become PHI in context

A person’s name and phone number may become sensitive when combined with a treatment, diagnosis, appointment type, or healthcare relationship. Minimize what HighLevel forms, calendars, pipelines, message previews, internal notifications, and URLs expose.

Avoid putting clinical details in:

• Calendar titles visible to external systems.
• SMS or email subject lines.
• URL query parameters.
• Pipeline card titles.
• Slack or chat notifications.
• Unencrypted exports.
• Tracking pixels or advertising audiences.

Use a neutral appointment label and let the approved clinical system hold clinical details when appropriate.

Messaging needs a channel-specific decision

Do not assume ordinary SMS, WhatsApp, or email is suitable for PHI because the CRM is HIPAA-enabled. The organization should decide what each channel can contain after its risk analysis, agreements, patient communication policy, and applicable rules.

Keep reminders minimal. For example, “You have an appointment at 3:00 PM” reveals less than a message containing a procedure, diagnosis, medication, or test result.

AI agents need strict scope and data handling

An AI receptionist can answer hours, explain non-clinical services, collect minimal contact details, and book an appointment. It should not diagnose, recommend treatment, or collect unnecessary medical history unless the full AI service, data path, agreement, and use case have been approved.

Review what enters prompts, call recordings, transcripts, summaries, knowledge bases, custom actions, and external model providers.

Sub-account transfer has a compliance dependency

HighLevel says a HIPAA-enabled sub-account can transfer to another agency only when the receiving agency already has the HIPAA add-on. Confirm this before initiating a transfer. Do not move the location first and solve the agreement later.

A practical HIPAA setup checklist for HighLevel

Governance

• Identify covered entity and business associate roles.
• Execute the required BAAs.
• Complete a documented risk analysis and risk-management plan.
• Define permitted data and prohibited data for HighLevel.
• Assign a security and privacy owner.

Account controls

• Purchase and sign the HighLevel package through an authorized owner.
• Enable only the approved sub-accounts.
• Require MFA and unique user accounts.
• Apply least-privilege roles.
• Review agency access to client locations.
• Test user offboarding.
• Review audit logs on a defined schedule.

Data design

• Minimize PHI in forms, custom fields, pipelines, and conversations.
• Use neutral appointment and opportunity labels.
• Define retention and deletion rules.
• Avoid PHI in URLs and ad-platform fields.
• Protect exports and local files.

Integrations

• Inventory every connected provider and webhook.
• Verify required BAAs and security terms.
• Review calendars, phone, SMS, email, AI, analytics, payment, and document services.
• Disable unnecessary connections.
• Test that workflows send only the minimum required data.

Operations

• Train staff on approved use.
• Define incident detection and reporting.
• Review access regularly.
• Test backup and continuity procedures.
• Audit new workflows before publication.

Test with synthetic data

Use fictional contacts and appointments for implementation QA. Do not use a real patient’s PHI to test a workflow, screenshot, AI prompt, webhook, or support ticket.

Test:

1. User login and MFA.
2. Access boundaries between roles.
3. Audit log visibility.
4. Appointment reminders with neutral text.
5. Internal notifications without clinical details.
6. Webhook payloads with the minimum fields.
7. User offboarding.
8. Export handling and storage.

Record the expected result and evidence. A compliance control that has never been tested is only an assumption.

Frequently asked questions