Is PostHog HIPAA Compliant? Self-Hosted Analytics for Healthcare Explained

PostHog is conditionally HIPAA compliant, but only when self-hosted on your own infrastructure with a signed Business Associate Agreement (BAA) in place. The critical condition: if you self-host PostHog, the entire compliance burden (encryption, access controls, audit logging, breach response, and vulnerability patching) shifts to your engineering team. As of July 2026, PostHog does not sign BAAs for its cloud-hosted product, meaning the cloud version is not suitable for processing protected health information (PHI). This distinction matters enormously for healthcare organizations asking "is PostHog HIPAA compliant," because the answer depends entirely on deployment method and internal resources.

TL;DR

• PostHog Cloud (the managed SaaS product) does not offer a BAA and is not HIPAA compliant for healthcare use involving PHI.
• PostHog self-hosted can be made HIPAA compliant, but your organization bears full responsibility for server security, encryption, access controls, and audit logging.
• A BAA with PostHog is available only for the self-hosted deployment; confirm current terms directly with PostHog, as these policies evolve.
• Self-hosted analytics for HIPAA requires dedicated DevOps resources, ongoing patching, and documented security procedures that many healthcare marketing teams lack.
• HHS OCR's December 2022 guidance on online tracking technologies makes clear that analytics tools processing PHI require a BAA and full HIPAA safeguards regardless of deployment model.
• Managed HIPAA-compliant analytics platforms eliminate the infrastructure burden while still providing a signed BAA and PHI-safe data handling.

What PostHog Does With Visitor and Patient Data

PostHog is an open-source product analytics platform that captures events, session recordings, feature flags, and user properties. In a healthcare context, the data PostHog collects can easily constitute PHI: IP addresses combined with health-related page visits, form submissions containing medical details, session replays showing diagnostic or treatment information, and user identification tied to patient accounts.

On PostHog Cloud, this data is stored on PostHog's infrastructure (hosted on AWS in the US or EU). On a self-hosted deployment, the data resides on servers you control. The distinction is not cosmetic; it determines who is the data custodian and who must implement the HIPAA Security Rule's administrative, physical, and technical safeguards.

BAA Availability and Terms

PostHog has historically offered a BAA for self-hosted enterprise customers. This means PostHog acknowledges its role as a business associate only in the context where the software runs on your infrastructure and PostHog provides support or maintenance access. For the cloud product, PostHog's publicly stated position is that they do not sign BAAs and recommend self-hosting for HIPAA-covered use cases.

Healthcare organizations should confirm current BAA terms directly with PostHog's sales team, as vendor policies on this point change frequently. The presence of a BAA alone does not make a deployment compliant; it is a necessary but insufficient condition.

Self-Hosted Analytics for HIPAA: What It Actually Requires

Self-hosted analytics for HIPAA is sometimes presented as a silver bullet: keep the data on your own servers and the compliance problem disappears. In practice, it introduces a significant operational commitment. Here is what HHS OCR expects when you process PHI through a self-hosted analytics tool:

Technical Safeguards You Must Implement

• Encryption at rest (AES-256 or equivalent) for all databases and storage volumes containing PHI
• Encryption in transit (TLS 1.2+) for all data flowing between the browser, your servers, and any connected services
• Unique user authentication and role-based access controls for every person who can access the analytics data
• Automatic session timeouts and multi-factor authentication for admin access
• Audit logging that records who accessed what data and when, retained for a minimum of six years per HIPAA requirements
• Integrity controls to detect unauthorized alteration of PHI

Administrative Safeguards You Must Maintain

• A documented risk assessment covering the self-hosted analytics environment
• Written policies for data retention, disposal, and breach notification
• Workforce training specific to the analytics platform and its PHI exposure
• A designated security official responsible for the deployment
• Incident response procedures covering potential breaches originating from the analytics system

Ongoing Operational Costs

• Patch management for PostHog releases, underlying OS, container orchestration (Kubernetes or Docker), and database engines
• Monitoring for uptime, performance, and security anomalies
• Backup and disaster recovery testing
• Periodic penetration testing and vulnerability scanning
• Infrastructure costs (cloud compute, storage, networking) that scale with traffic volume

Many healthcare marketing teams underestimate these requirements. A self-hosted deployment that is not continuously maintained becomes a liability rather than a compliance asset. If a breach occurs due to an unpatched vulnerability, the covered entity (your organization) bears the full enforcement risk.

HHS OCR Guidance and What It Means for PostHog

The HHS Office for Civil Rights issued guidance in December 2022 (updated in March 2024) specifically addressing online tracking technologies used by HIPAA-covered entities and their business associates. The guidance states that tracking technologies on pages where individuals access health information or services create PHI when combined with individual identifiers (including IP addresses and device IDs).

Under this guidance, any analytics tool that collects such data must operate under a valid BAA, implement the minimum necessary standard, and apply the full suite of HIPAA Security Rule safeguards. This applies equally whether the tool is cloud-hosted or self-hosted. The deployment model does not exempt you from the rule; it simply changes who is responsible for compliance.

The FTC has separately enforced against health-adjacent companies under the Health Breach Notification Rule, as seen in the BetterHelp and GoodRx settlements. State laws like Washington's My Health My Data Act (MHMDA) add further obligations around consent and data sale restrictions that apply even to non-covered entities.

Configurations That Are Safe vs. Unsafe for Healthcare

Unsafe Configurations

• Using PostHog Cloud without a BAA on any page where patients log in, book appointments, submit health information, or view treatment details
• Self-hosting PostHog without encryption at rest or in transit
• Granting broad admin access to marketing team members without role-based restrictions or audit logging
• Enabling session replay on pages containing PHI without implementing data masking for sensitive fields
• Sending PostHog event data to third-party integrations (Slack, email tools, data warehouses) without ensuring those downstream tools also have BAAs and PHI protections

Safer Configurations (Self-Hosted)

• Deploying PostHog on a dedicated, hardened Kubernetes cluster within your existing HIPAA-compliant cloud environment (AWS, GCP, or Azure with BAAs in place)
• Enabling full-disk encryption and TLS for all endpoints
• Configuring PostHog to exclude or mask PHI fields before storage (property filters, event exclusions)
• Restricting data access to named individuals with documented need-to-know justification
• Maintaining audit logs and integrating them with your SIEM or compliance monitoring stack
• Documenting the deployment in your organization's HIPAA risk assessment

The Real Cost of Self-Hosting for Healthcare Marketing Teams

For digital health startups with strong engineering teams and existing Kubernetes infrastructure, self-hosted PostHog can work. For healthcare practices, hospital marketing departments, and telehealth companies whose core competency is not infrastructure management, self-hosting introduces a disproportionate burden. The analytics platform becomes another production system to maintain, secure, and audit.

This is the same tradeoff that applies to other self-hosted analytics tools. As explored in our comparison of Matomo vs Curve for Healthcare: Self-Hosted Analytics or Managed HIPAA Compliance, the self-hosted path trades one problem (vendor compliance) for another (infrastructure compliance). Both are solvable, but they require different skill sets and budgets.

How PostHog Compares to Other Analytics Tools for Healthcare

PostHog occupies a unique position as an open-source, product-analytics-first platform. Other tools in adjacent categories face similar HIPAA questions:

Google Analytics 4, for example, does not offer a BAA and is not HIPAA compliant for healthcare use; we detail this in Is Google Analytics 4 HIPAA Compliant? No -- Here Are 3 Alternatives That Are. Product analytics platforms like Mixpanel and Amplitude present their own compliance challenges, covered in Is Mixpanel HIPAA Compliant? Product Analytics Rules for Digital Health and Is Amplitude HIPAA Compliant? What Digital Health Teams Need to Know.

For a broader comparison of managed HIPAA-compliant analytics options, see Freshpaint vs Curve vs Piwik PRO: HIPAA-Compliant Analytics Compared for Healthcare Practices.

Safe-Use Checklist: PostHog for HIPAA-Covered Entities

If you decide to proceed with PostHog in a healthcare environment, use this checklist to evaluate your readiness:

Before Deployment

• Confirm that PostHog will sign a BAA for your self-hosted deployment and review its terms
• Ensure your hosting environment (AWS, GCP, Azure, or on-premises) already operates under a BAA with the infrastructure provider
• Assign a named security official responsible for the PostHog deployment
• Complete a risk assessment that specifically covers the analytics system
• Document which data elements PostHog will collect and whether any constitute PHI

During Configuration

• Enable encryption at rest and in transit for all PostHog data stores
• Configure property and event filters to minimize PHI collection (minimum necessary standard)
• Set up role-based access with individual credentials for every user
• Enable and test audit logging
• Mask sensitive fields in session replay if session recording is enabled
• Disable or restrict third-party integrations that lack BAAs

Ongoing Operations

• Patch PostHog and all dependencies within your organization's vulnerability management SLA
• Monitor access logs for anomalies
• Conduct periodic access reviews (quarterly recommended)
• Test backup and restore procedures
• Update your risk assessment annually or after significant changes
• Maintain breach notification procedures specific to the analytics environment

When a Managed HIPAA-Compliant Platform Makes More Sense

Self-hosting is not the wrong choice universally, but it is the wrong choice for teams that lack dedicated DevOps and security resources. If your organization wants analytics, session replay, form tracking, and ad conversion data without building and maintaining HIPAA infrastructure, a managed platform purpose-built for healthcare is a more practical path.

Curve is a HIPAA-compliant tracking and analytics platform that provides a signed BAA, PHI-safe server-side conversion delivery to Google, Meta, and Microsoft ad platforms, session replay, form analytics, and marketing attribution built specifically for healthcare marketers. Because Curve manages the infrastructure, encryption, access controls, and audit logging, your team can focus on marketing performance rather than server security. If the self-hosted path described above feels like more than your team can responsibly maintain, Curve is worth evaluating.

Frequently Asked Questions

Can I use PostHog Cloud for my healthcare website if I do not collect patient names?

No. Under HHS OCR guidance, PHI is not limited to names. IP addresses, device identifiers, and browsing behavior on health-related pages constitute PHI when collected by a HIPAA-covered entity. PostHog Cloud does not offer a BAA, so it cannot be used on pages where such data is generated, regardless of whether you collect explicit patient names.

Does self-hosting PostHog automatically make it HIPAA compliant?

No. Self-hosting means you control the data, but HIPAA compliance requires encryption, access controls, audit logging, risk assessments, workforce training, and documented policies. Simply deploying PostHog on your own server without these safeguards does not satisfy HIPAA requirements and could expose you to enforcement action in the event of a breach.

What happens if PostHog releases an update and I do not patch my self-hosted instance?

Unpatched software with known vulnerabilities violates the HIPAA Security Rule's requirement to protect against reasonably anticipated threats. If a breach occurs through an unpatched vulnerability, HHS OCR may consider this willful neglect, which carries higher penalty tiers (up to $1.5 million per violation category per year under the HITECH Act penalty structure).

Is PostHog a better HIPAA option than Google Analytics?

PostHog's self-hosted option provides a path to HIPAA compliance that Google Analytics does not offer at all (Google will not sign a BAA for GA4). However, "better" depends on your team's ability to maintain the infrastructure. A fully managed HIPAA-compliant analytics platform removes this burden entirely while still providing a valid BAA and PHI protections.

Can I use PostHog session replay on patient portal pages?

Only if you self-host with full HIPAA safeguards and configure data masking to exclude sensitive health information from recordings. Even then, you must ensure that only authorized personnel can view recordings, that access is logged, and that recordings are retained and disposed of according to your data retention policy. Many organizations choose to disable session replay on patient-facing pages to reduce risk.

Does PostHog sell or share my data with third parties?

In the self-hosted model, PostHog does not have access to your data (it resides on your servers). In the cloud model, PostHog's privacy policy governs data handling; review it carefully. However, the cloud model's lack of a BAA makes this question secondary for healthcare organizations, since you should not be sending PHI to PostHog Cloud regardless of their data-sharing practices.