Statsig alternative for HIPAA workloads

Statsig alternative for HIPAA workloads: what the Security Rule requires

If your experiments or feature flags touch electronic protected health information (ePHI), the first question is whether the HIPAA Security Rule applies to you and to your vendor. It applies to covered entities (health plans, health care clearinghouses and covered health care providers) and to their business associates, for all ePHI they create, receive, maintain or transmit (45 CFR 164.302). Statsig lists HIPAA eligibility with a business associate agreement (BAA) as an Enterprise feature, and its warehouse native deployment also sits in the Enterprise plan, according to the Statsig pricing page. A team on a lower tier should confirm with Statsig in writing whether a BAA is available to it before any ePHI reaches the platform. There is no HIPAA certification to ask for. HHS states that no Security Rule standard requires certifying compliance, so any vendor claim of a HIPAA certificate should be treated as a marketing statement that needs a contract reference.

The short answer is that self-hosted GrowthBook can fit a HIPAA environment if your organization operates the safeguards itself. GrowthBook's free self-hosted Open Source plan and the paid self-hosted Enterprise tier are both self-managed, and its data source documentation describes read-only SELECT queries against your own warehouse, with only aggregated statistics returned. That design keeps event data in your warehouse, so the business associate question narrows to the components GrowthBook itself touches: the application, its MongoDB or compatible metadata store, and the warehouse credentials. Your organization, not GrowthBook, would hold the BAA obligations for the infrastructure it runs. Confirm with counsel whether any experiment metadata or SDK traffic could contain ePHI, such as user identifiers or attributes used in targeting, and minimize those fields before rollout.

Once self-hosted, the Security Rule safeguards become your responsibility. Map them to your own control set before go-live. The technical safeguards in 45 CFR 164.312 include unique user identification and emergency access procedures as required specifications, and automatic logoff and encryption as addressable ones, so decide how each will be met in your deployment and document why. Any cloud provider or managed database hosting ePHI-adjacent data needs its own BAA. Your own risk analysis, under the administrative safeguards in 164.308, should cover the GrowthBook host, the database, the warehouse role and the SDK paths. Ask an independent assessor to test these controls, because the HHS Office for Civil Rights enforces the rule through complaints, compliance reviews and audits, and it does not accept a vendor certificate in their place.

Which HIPAA requirements apply to an experimentation stack

An experimentation stack touches protected health information only when flags, targeting or event data carry patient-linked identifiers, but the rules apply to the whole chain once they do. The cards below cover the parallel obligations that sit around GrowthBook, from deciding whether your organization is in scope to the contracts and penalties that follow from getting it wrong.

Scope as covered entity or business associate

The HIPAA Security Rule applies to covered entities and their business associates for all electronic protected health information they create, receive, maintain or transmit (45 CFR 164.302). Whether your experiment data counts depends on whether it contains ePHI, so classify event payloads, user IDs and targeting attributes before deciding the stack is out of scope. Confirm with your privacy officer which role your organization holds for each data flow.

Administrative, physical and technical standards

Appendix A to Subpart C lists 18 standards across administrative, physical and technical safeguards, with 36 implementation specifications, of which 14 are required and 22 addressable. Each one maps to a different part of the stack, from workforce access to GrowthBook to the hosts and database behind it. Treat the matrix as a checklist you must document against, not a list you can satisfy with one tool.

Five technical safeguards and their seven specifications

The technical safeguards in 45 CFR 164.312 carry 7 implementation specifications. Unique user identification and an emergency access procedure are required, while automatic logoff and both encryption specifications are addressable. For a self-hosted GrowthBook, this means named accounts for every analyst and administrator, a tested break-glass path, and a documented decision on encrypting data at rest and in transit.

Business associate contract terms

Under 45 CFR 164.314(a)(2)(i), a business associate contract must require the business associate to comply with the Security Rule, flow the same terms down to subcontractors that handle ePHI, and report security incidents, including breaches of unsecured PHI. If a vendor hosts or touches ePHI for you, check that its contract includes these terms. Self-hosting shifts most of these duties to your own team, but your contracts with your cloud provider and any integrator still need reviewing.

Civil money penalties

Under 45 CFR 102.3, the inflation-adjusted civil money penalty for penalties assessed on or after 28 January 2026 ranges from $145 to $2,190,294 per violation, with a calendar-year cap of $2,190,294. The range is a reason to document decisions early, since each undocumented control can be counted separately. Ask legal counsel how exposure is calculated for your organization's specific violation categories.

Pending Security Rule revision

HHS proposed a major Security Rule revision on 6 January 2025 (90 FR 898). As of October 2026 no final rule has been published, and the Unified Agenda projects final action for July 2027. The proposal would change what organizations must document and test, so build your evidence to be adjustable. Track RIN 0945-AA22 and plan a review cycle before the final text lands.

How Statsig and self-hosted GrowthBook compare by deployment

Statsig's hosted plans run flags and experiments on Statsig's infrastructure, and the pricing page bills these plans on analytics events. Statsig lists HIPAA eligibility with a business associate agreement (BAA) as an Enterprise feature, so the standard cloud tier should not be assumed to cover electronic protected health information (ePHI). Confirm the position with the vendor before any event carries patient data.

Where data sits: Event and assignment data is processed in Statsig's hosted environment. Ask for the hosting region, subprocessors and retention settings in writing.
BAA status: The standard tier is not the documented route to HIPAA eligibility. Ask whether a BAA is available on your plan before onboarding.
Event volume: Costs scale with analytics events, so teams that send rich user attributes may transmit more data than the experiment needs.
What you own: Access reviews, change logs for gates, and the data minimization rules that govern what your SDK sends to the vendor.

Check the order form for the named plan, the BAA clause and the data location before you treat this tab as a yes.

Which open-source option fits a HIPAA constraint, and the trade-offs

This table compares self-hosted GrowthBook Open Source, self-hosted GrowthBook Enterprise, and Unleash or Flagsmith for feature flags only, on how each fits a HIPAA environment, its license, its project limits and its trade-offs. Read it as a starting point: none of these options is a HIPAA certification, and the supplied facts do not show warehouse-native analysis for Unleash or Flagsmith, so confirm that before relying on it.

Requirement or attribute	GrowthBook self-hosted Open Source	GrowthBook self-hosted Enterprise	Unleash or Flagsmith (flags only)
How it fits the constraint	Runs in your own HIPAA environment, with experiment queries sent as read-only SELECT statements to your warehouse and only aggregates returned	Same deployment model, adding SSO, SCIM, advanced permissioning and approval workflows that help enforce access controls	Self-hosted flag management keeps flag data on your servers, but warehouse-native analysis is not shown in the supplied facts; confirm before relying on it
Licensing	MIT Expat outside the enterprise directories, which the free tier uses	Enterprise directories fall under the GrowthBook Enterprise License, so review that license with counsel	Unleash moved its server to AGPLv3 with v8.0.0; Flagsmith is mostly BSD 3-Clause with closed-source Enterprise features
Project limits	1 project with unlimited users and unlimited API requests, per the GrowthBook pricing page	Multiple projects and enterprise controls are priced as custom Enterprise terms; ask the vendor for current limits	Unleash Open Source allows 1 project and 2 environments; Flagsmith states its open-source version has no API request limits
Single sign-on and access control	No SSO, SCIM, advanced permissioning or approval workflows, so access reviews rely on manual procedures you document	SSO, SCIM, advanced permissioning and approval workflows are included	Access control depends on the edition; confirm SSO and role controls in the version you deploy
Audit evidence you produce	You build logging, access review and change records from your own tooling	Approval workflows add change records that assessors can review, but you still produce the evidence	Depends on the chosen edition and your logging stack; confirm audit log features with the vendor
Trade-offs to plan for	Your team operates the stack, backups, encryption and access reviews, and must sign a business associate agreement with any vendor that handles ePHI	Adds licensing cost and the same operational duties, plus the Enterprise license review	Feature flags only in this comparison; experimentation and warehouse analysis need a separate tool or confirmed capability

How warehouse-native analysis keeps ePHI in your environment

GrowthBook analyzes experiments by running only SELECT queries against your own data source and receiving only aggregated statistics back, so event-level records can stay in the warehouse your HIPAA environment already controls. The supported sources include BigQuery, Snowflake, Redshift, Databricks, Postgres, MySQL and SQL Server, among others. Before go-live, confirm with your security team that the database role used by GrowthBook is read-only, limited to the schemas and tables needed for experiments, and sits inside the same network boundary and encryption controls as the rest of your ePHI stores. The GrowthBook data source documentation is the reference for what the connection does and does not transmit.

The data path has five parts. Your application uses a GrowthBook SDK to evaluate flags and report exposures. The GrowthBook service (the Next.js front end, Express API and Python statistics engine, packaged in one Docker image) holds flag definitions and experiment configuration. Metadata sits in MongoDB or a compatible store, which the self-hosting documentation recommends running as a managed service for production. Uploaded files can go to local storage, Amazon S3 or Google Cloud Storage. Event-level data stays in the warehouse, and only aggregates return to the statistics engine. Each of these stores needs its own access control, encryption and backup scope in your risk analysis, because the warehouse is not the only place data lives.

Flag evaluation metadata, user attributes and logs can still contain identifiers. Targeting rules, SDK attributes, exposure payloads and application logs often carry patient or member IDs, account numbers or email addresses if engineers pass them in for convenience. Scope attributes to opaque, non-identifying keys, review what the SDK sends by default, and keep log levels and request capture from writing attribute values to disk. Confirm the retention period for MongoDB collections and file uploads, and include them in your access reviews, audit logging and business associate analysis under 45 CFR 164.308 and 164.312.

How to deploy self-hosted GrowthBook inside a HIPAA environment

This sequence takes a team from confirming its HIPAA role and data flows to a GrowthBook deployment inside its own HIPAA-eligible environment, with the access, logging, backup and contract controls that the team must own.

Confirm HIPAA role and data flows
Legal, privacy and security leads decide whether the organization acts as a covered entity or a business associate, and map which systems create, receive, maintain or transmit ePHI. Engineering documents every path by which experiment data could reach GrowthBook, including SDK calls, exports and warehouse queries. The step closes when the team has a signed data flow diagram and a written decision on whether any ePHI can enter the experimentation system at all.
Limit events and attributes in experiments
Product and data owners list the events, user attributes and experiment assignments that the experimentation tool actually needs. Anything that identifies a patient, such as names, record numbers or free-text clinical fields, is excluded or replaced with a pseudonymous identifier before it reaches the SDK or the warehouse. The step closes when the approved attribute list is documented and the SDK payloads have been reviewed against it.
Deploy GrowthBook in a HIPAA-eligible environment
The platform team deploys the GrowthBook Docker image or the official Helm chart for Kubernetes into a cloud account or data center that the organization has confirmed is HIPAA-eligible. The image bundles the Next.js front end, Express API and Python statistics engine, so the team deploys one application unit plus its supporting services. The step closes when the instance runs inside the approved network boundary and is reachable only through the internal access path the team has defined.
Provision encrypted managed MongoDB-compatible storage
GrowthBook stores metadata in MongoDB or a compatible database, and its self-hosting documentation suggests a managed service such as MongoDB Atlas or AWS DocumentDB for production. The platform team confirms with the provider which encryption, network isolation and access control features are available in the chosen tier, then configures encryption at rest, private networking and database users limited to the GrowthBook service. The step closes when the team can show the encryption settings and the connection restrictions in the provider console.
Configure a read-only warehouse role
The data team creates a dedicated database role in the warehouse, such as Snowflake, BigQuery or another supported source, with SELECT privileges only on the tables and views approved in step two. GrowthBook runs read-only SELECT queries and sends back only aggregated statistics, so the role should have no write, DDL or access to unapproved schemas. The step closes when a test query succeeds against the approved objects and a write attempt is refused by the warehouse.
Enforce identity, emergency access and logoff
The security team connects GrowthBook to the organization's identity provider and assigns each person a unique user account, which maps to the unique user identification standard in the HIPAA technical safeguards. The team also writes an emergency access procedure, sets an automatic logoff interval and records which of these controls are required and which are addressable, as summarized in the Security Rule matrix. The paid self-hosted Enterprise tier includes SSO and SCIM, so the team confirms that tier covers its needs. The step closes when a test login is tied to a named user and the emergency and logoff procedures are signed off.
Import existing flags from LaunchDarkly or Statsig
If the team is migrating, it runs GrowthBook's documented importer for LaunchDarkly, which reads projects, environments and flags through a REST API access token, or the Statsig importer, which reads objects through a read-only Console API key. The team reviews the import preview, confirms that targeting rules and rollouts carried over correctly, and replaces the vendor SDK calls in the application because the importers do not change application code. The step closes when imported flags match the source system in a side-by-side review and the application no longer calls the old SDK.
Set logging, backups and vendor agreements
The operations team turns on application and database logging, routes it to the organization's approved log store, and sets backup and restore procedures for MongoDB and any file storage, such as Amazon S3 or Google Cloud Storage. Compliance obtains business associate agreements from the cloud provider, the managed database provider and any other subcontractor that touches ePHI, as required by the business associate contract rules in 45 CFR 164.314. The step closes when a restore test has succeeded and every hosting and subcontracted provider has a signed agreement on file.

The safeguards you own after a self-hosted move

Moving experiment data into your own environment moves the Security Rule obligations with it. The cards below cover the safeguard families that a self-hosted GrowthBook deployment makes you responsible for, and each one needs an owner, a configuration and evidence before go-live.

Access control and unique user identification

Every person who edits flags, reads results or connects a warehouse needs a unique account, and shared logins do not meet the access control standard. Map GrowthBook roles to who actually needs to change a flag or see patient-adjacent metrics, and confirm that SSO, SCIM and advanced permissioning are available in the edition you choose, since the free self-hosted Open Source plan does not include them. Check that offboarding removes access in both GrowthBook and the warehouse.

Audit logging and activity review

Flag changes, experiment launches and data source edits can alter what users see and which data is queried, so you need a record of who changed what and when. Confirm what GrowthBook records natively, where logs are retained, and whether they reach your central log store. Assign a named owner who reviews these logs on a set schedule and keeps evidence of that review.

Encryption in transit and at rest

Encrypt connections between browsers, the GrowthBook API and the metadata database, and between GrowthBook and each warehouse connection. Metadata lives in MongoDB or a compatible database, so the encryption settings, key management and backups of that database are your responsibility. Document which encryption specifications you treat as addressable and how you reached that decision.

Backup and emergency access

Back up the MongoDB metadata store and any file uploads held in local, Amazon S3 or Google Cloud Storage, and test restores rather than assuming them. Define a break-glass procedure that lets an authorized administrator restore GrowthBook when the normal identity provider is down, and record who can invoke it. Both the backup and emergency access controls need written procedures and tested evidence.

Vendor and subcontractor agreements under 164.314

If a managed hosting provider, database service or consultant handles ePHI on your behalf, the business associate contract must require Security Rule compliance, flow the same terms to subcontractors and require incident reporting. Ask each vendor whether it will sign a BAA, and map which vendor touches which data. Contracts with cloud providers and database services are the place to confirm these terms, not assumptions about their defaults.

Risk analysis and incident reporting

The Security Rule expects a documented risk analysis of where ePHI flows, including experiment events that carry identifiers and warehouse queries that touch clinical tables. Record each data path, the threats you considered and the controls you chose. Define an incident process that routes suspected breaches of unsecured PHI to the covered entity within the timeline in your business associate contract. NIST SP 800-66 Rev. 2 is a practical guide to implementing the rule, not a certification, and no HIPAA certification exists.

What evidence a HIPAA review asks for from an experimentation stack

Does HHS certify that our experimentation stack is HIPAA compliant?

No. HHS states that no Security Rule standard requires an entity to certify compliance, and private certifications do not stop HHS from later finding a violation. The HHS Office for Civil Rights enforces the rule through complaints, compliance reviews and audits, so the evidence you keep is what gets examined. Any claim that a vendor or tool is "HIPAA certified" should be treated with caution and checked against the contract and your own records.

What risk analysis documentation should cover GrowthBook?

The Security Rule expects a documented risk analysis of the electronic protected health information your systems create, receive, maintain or transmit. For a self-hosted GrowthBook deployment, that analysis should name each data path: the application database, the warehouse connections, the SDK traffic from your applications and any file storage. Record the threats you considered, the controls you chose and why, and the residual risk you accepted. Review it when the architecture changes or a new version such as v5.1.0, released September 22, 2026, alters how components behave.

Which policies and procedures must we write for the experimentation platform?

Your written policies should cover who may create, change or retire flags and experiments, how production changes are approved, how user access is granted and removed, and how backups and restores are tested. Procedures should show how each policy is carried out in practice. Keep them current and dated, and link them to the risk analysis so a reviewer can trace a control back to the risk it addresses.

What access review records do auditors expect for GrowthBook users?

Auditors typically look for evidence that access is granted on a documented need, reviewed on a schedule and removed promptly when people change roles or leave. For GrowthBook, keep exports of user lists, roles and permissions for each project, the approval record for each change, and the date of each review with the reviewer's name. If you run self-hosted Enterprise with SSO and SCIM, the identity provider's provisioning logs become part of this evidence. Confirm the exact role model and audit log output with GrowthBook for your version.

What business associate agreement records should we keep for this stack?

Keep an inventory of every business associate relationship that touches ePHI in the experimentation path, including your cloud provider, managed database service and any support provider with access to the environment. Each relationship should have a signed business associate contract that meets 45 CFR 164.314(a)(2)(i), which requires compliance with the Security Rule, flow-down to subcontractors that handle ePHI, and reporting of security incidents. Self-hosting does not remove the need for these agreements where a third party can access ePHI.

What configuration, change and warehouse query records should we retain?

A reviewer will want to see how the deployment was built and how it changed. Keep the Helm values or Docker image tags you deployed, the version history of GrowthBook releases applied, change tickets for each upgrade and configuration change, and the approval for each. On the data side, retain warehouse query logs showing that GrowthBook ran read-only SELECT queries against your sources, along with the service account permissions that enforce read-only access. Confirm with your warehouse team how long query history is retained.

What incident response records and HITRUST assessments do we need?

Keep an incident response plan that names the people who triage events affecting the experimentation stack, plus records of past exercises and incidents, including how security incidents were reported to covered entities under your business associate contracts. HITRUST r2 and e1 assessments are optional third-party attestations issued by independent assessors, not HHS requirements, so they are a choice you make for customer or contractual reasons. Confirm with your assessor which control specifications apply to a self-hosted analytics tool before you scope one.

When a self-hosted HIPAA setup is the wrong choice

Self-hosting GrowthBook inside your own HIPAA environment only makes sense if you have people who can own the safeguards for the life of the deployment. Statsig Enterprise, which lists HIPAA eligibility with a BAA as an Enterprise feature, is the better fit if your team cannot staff ongoing access reviews, logging, patching, backups, incident response and the business associate paperwork that comes with running the stack yourself. Ask Statsig directly what its BAA covers and whether it extends to the features you plan to use, and compare that answer with the internal time you can realistically commit to the controls listed in the next section.

Be realistic about the feature gap. The free self-hosted GrowthBook Open Source plan omits SSO and SCIM, advanced permissioning, approval workflows, safe rollouts and holdouts, which are the controls many compliance teams expect to see around who can change a flag that affects patient-facing behavior. Self-hosted Enterprise adds these features on a paid basis, so confirm current pricing and entitlements on the GrowthBook pricing page before you assume the free tier meets your access control requirements. If you need approval workflows and SSO but do not want to take on the license and support relationship, a managed vendor with a signed BAA may be the simpler route.

Also consider whether you need product analytics in the same tool. If Statsig is serving as your flags, experiments and analytics platform together, moving only the experimentation layer leaves a separate analytics system to host, secure and cover under its own risk assessment. HIPAA penalties apply to the covered entity or business associate regardless of hosting model, so self-hosting does not shift liability away from you. The HIPAA Security Rule revision proposed on 6 January 2025 could also change requirements, and the Unified Agenda projects final action for July 2027, so plan for possible changes to safeguards and documentation rather than treating today's controls as fixed.

How DeployOpen deploys GrowthBook under HIPAA constraints

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so GrowthBook can run in the HIPAA environment you already operate. We prepare the systems, controls and evidence that a compliance assessment will examine, but we do not issue HIPAA attestations or certifications.

How we scope

We confirm which experiments, flags and warehouse sources will carry ePHI, and which will not.
The written scope names the cloud accounts, data centers or air-gapped networks where GrowthBook will run.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

We deploy the GrowthBook image or Helm chart in your environment, with MongoDB or a compatible managed database.
We configure read-only warehouse connections so experiment queries return only aggregated statistics.
We test access controls, encryption, logging and backups against the safeguards your team has assigned to each component.

How we hand over

We document the architecture, data flows, access model and the safeguards your organization owns.
We provide runbooks for backups, restores, upgrades and incident response for the GrowthBook deployment.
We prepare the control evidence your assessors or auditors will request, and they make the final determination.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
We can plan and test upgrades when new GrowthBook releases change the licensed or self-hosted feature set.
We can re-scope the work when your warehouse, business associate agreements or HIPAA obligations change.

Statsig alternative for HIPAA workloads